These articles are re-published by JavaCodeGeeks.com. It’s a awesome resource for Java developers, I highly recommend to read me there :)
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US" itemscope="" itemtype="http://schema.org/WebSite"> <head>
</div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/06/17/dont-use-java-assertions.html>12 Best</li> <li /2016/06/17/dont-use-java-assertions.html>All 292</li> <li /2016/06/17/dont-use-java-assertions.html>Webinars</li> <li /2016/06/17/dont-use-java-assertions.html>Talks</li> <li /2016/06/17/dont-use-java-assertions.html>Books</li> <li /2016/06/17/dont-use-java-assertions.html>Papers</li> <li /2016/06/17/dont-use-java-assertions.html>Pets</li> <li /2016/06/17/dont-use-java-assertions.html class=”highlighted”>Trainings</li> <li /2016/06/17/dont-use-java-assertions.html>Award</li> <li /2016/06/17/dont-use-java-assertions.html>Testimonials</li> <li /2016/06/17/dont-use-java-assertions.html>Shift-M</li> <li /2016/06/17/dont-use-java-assertions.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/06/17/dont-use-java-assertions.html</p><h1 itemprop="name headline mainEntityOfPage">Don’t Use Java Assertions</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Los Angeles, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>There are basically two ways to validate a situation in Java and complain when something unexpected happens. It’s either an exception or an assertion. Technically, they are almost the same, but there are some small differences. I believe that exceptions are the right way to go in all situations and assertions should never be used. Here’s why.</p>
<figcaption id="44ce340c">Natural Born Killers (1994) by Oliver Stone</figcaption>public class Main { public static void main(String... args) { assert true == false : "There is a problem"; System.out.println("Hello, world!"); } }</pre>Main.java and compile:</p>$ javac Main.java</pre>$ java Main Hello, world!</pre>-enableassertions flag:</p>$ java -enableassertions Main Exception in thread "main" java.lang.AssertionError: There is a problem at Main.main(Main.java:3)</pre>AssertionError. But hold on; it’s not a RuntimeException. It extends Error class, which extends Throwable. This is the second difference. I don’t know of any other differences.</p><p>I would recommend not to use assertions … ever. Simply because I strongly believe in the Fail Fast approach. I think bugs must be visible not only during testing but also in production. Moreover, I believe making bugs visible in production is very important if you want to achieve a high-quality product.</p><p>Thus, no assertions. They are simply a flawed and outdated feature in Java (and some other languages).</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>There are basically two ways to validate a situation in Java and complain when something unexpected happens. It’s either an exception or an assertion. Technically, they are almost the same, but there are some small differences. I believe that exceptions are the right way to go in all situations and assertions should never be used. Here’s why.</p><figcaption id="44ce340c">Natural Born Killers (1994) by Oliver Stone</figcaption>public class Main { public static void main(String... args) { assert true == false : "There is a problem"; System.out.println("Hello, world!"); } }</pre>Main.java and compile:</p>$ javac Main.java</pre>$ java Main Hello, world!</pre>-enableassertions flag:</p>$ java -enableassertions Main Exception in thread "main" java.lang.AssertionError: There is a problem at Main.main(Main.java:3)</pre>AssertionError. But hold on; it’s not a RuntimeException. It extends Error class, which extends Throwable. This is the second difference. I don’t know of any other differences.</p><p>I would recommend not to use assertions … ever. Simply because I strongly believe in the Fail Fast approach. I think bugs must be visible not only during testing but also in production. Moreover, I believe making bugs visible in production is very important if you want to achieve a high-quality product.</p><p>Thus, no assertions. They are simply a flawed and outdated feature in Java (and some other languages).</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/05/03/test-methods-must-share-nothing.html>12 Best</li> <li /2016/05/03/test-methods-must-share-nothing.html>All 292</li> <li /2016/05/03/test-methods-must-share-nothing.html>Webinars</li> <li /2016/05/03/test-methods-must-share-nothing.html>Talks</li> <li /2016/05/03/test-methods-must-share-nothing.html>Books</li> <li /2016/05/03/test-methods-must-share-nothing.html>Papers</li> <li /2016/05/03/test-methods-must-share-nothing.html>Pets</li> <li /2016/05/03/test-methods-must-share-nothing.html class=”highlighted”>Trainings</li> <li /2016/05/03/test-methods-must-share-nothing.html>Award</li> <li /2016/05/03/test-methods-must-share-nothing.html>Testimonials</li> <li /2016/05/03/test-methods-must-share-nothing.html>Shift-M</li> <li /2016/05/03/test-methods-must-share-nothing.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/05/03/test-methods-must-share-nothing.html</p><h1 itemprop="name headline mainEntityOfPage">Test Methods Must Share Nothing</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Palo Alto, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Constants… I wrote about them some time ago, mostly saying that they are a bad thing, if being public. They reduce duplication, but introduce coupling. A much better way to get rid of duplication is by creating new classes or methods—a traditional OOP method. This seems to make sense and in our projects I see less and less public constants. In some projects we don’t have them at all. But one thing still bothers me: unit tests. Most programmers seem to think that when static analysis says that there are too many similar literals in the same file, the best way to get rid of them is via a private static literal. This is just wrong.</p>
<figcaption id="934a9853">Oldeuboi (2003) by Chan-wook Park</figcaption>@Before and @BeforeClass features, but sometimes it’s just not possible. We may have, say, 20 test methods in one FooTest.java file. Preparing all objects in one “before” is not possible. So we have to do certain things again and again in our test methods.</p><p>Let’s take a look at one of the classes in our Takes Framework: VerboseListTest. It’s a unit test and it has a problem, which I’m trying to tell you about. Look at that MSG private literal. It is used for the first time in setUp() method as an argument of an object constructor and then in a few test methods to check how that object behaves. Let me simplify that code:</p>class FooTest { private static final String MSG = "something"; @Before public final void setUp() throws Exception { this.foo = new Foo(FooTest.MSG); } @Test public void simplyWorks() throws IOException { assertThat( foo.doSomething(), containsString(FooTest.MSG) ); } @Test public void simplyWorksAgain() throws IOException { assertThat( foo.doSomethingElse(), containsString(FooTest.MSG) ); } }</pre>VerboseListTest and it’s very wrong. Why? Because this shared literal MSG introduced an unnatural coupling between these two test methods. They have nothing in common, because they test different behaviors of class Foo. But this private constant ties them together. Now they are somehow related.</p><p>If and when I want to modify one of the test methods, I may need to modify the other one too. Say I want to see how doSomethingElse() behaves if the encapsulated message is an empty string. What do I do? I change the value of the constant FooTest.MSG, which is used by another test method. This is called coupling. And it’s a bad thing.</p><p>What do we do? Well, we can use that "something" string literal in both test methods:</p>class FooTest { @Test public void simplyWorks() throws IOException { assertThat( new Foo("something").doSomething(), containsString("something") ); } @Test public void simplyWorksAgain() throws IOException { assertThat( new Foo("something").doSomethingElse(), containsString("something") ); } }</pre>setUp() method and the private static literal MSG. What do we have now? Code duplication. String "something" shows up four times in the test class. No static analyzers will tolerate that. Moreover, there are seven (!) test methods in VerboseListTest, which are using MSG. Thus, we will have 14 occurrences of "something", right? Yes, that’s right and that’s most likely why one of authors of this test case introduced the constant—to get rid of duplication. BTW, @Happy-Neko did that in pull request #513, @carlosmiranda reviewed the code and I approved the changes. So, three people made/approved that mistake, including myself.</p><p>So what is the right approach that will avoid code duplication and at the same time won’t introduce coupling? Here it is:</p>class FooTest { @Test public void simplyWorks() throws IOException { final String msg = "something"; assertThat( new Foo(msg).doSomething(), containsString(msg) ); } @Test public void simplyWorksAgain() throws IOException { final String msg = "something else"; assertThat( new Foo(msg).doSomethingElse(), containsString(msg) ); } }</pre>"something" in so many places. It questions us—why are they the same? Is it really so important to use "something" everywhere? Why can’t you use different literals? Of course we can. And we should.</p><p>The bottom line is that each test method must have its own set of data and objects. They must not be shared between test methods ever. Test methods must always be independent, having nothing in common.</p><p>Having that in mind, we can easily conclude that methods like setUp() or any shared variables in test classes are evil. They must not be used and simply must not exist. I think that their invention in JUnit caused a lot of harm to Java code.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Constants… I wrote about them some time ago, mostly saying that they are a bad thing, if being public. They reduce duplication, but introduce coupling. A much better way to get rid of duplication is by creating new classes or methods—a traditional OOP method. This seems to make sense and in our projects I see less and less public constants. In some projects we don’t have them at all. But one thing still bothers me: unit tests. Most programmers seem to think that when static analysis says that there are too many similar literals in the same file, the best way to get rid of them is via a private static literal. This is just wrong.</p><figcaption id="934a9853">Oldeuboi (2003) by Chan-wook Park</figcaption>@Before and @BeforeClass features, but sometimes it’s just not possible. We may have, say, 20 test methods in one FooTest.java file. Preparing all objects in one “before” is not possible. So we have to do certain things again and again in our test methods.</p><p>Let’s take a look at one of the classes in our Takes Framework: VerboseListTest. It’s a unit test and it has a problem, which I’m trying to tell you about. Look at that MSG private literal. It is used for the first time in setUp() method as an argument of an object constructor and then in a few test methods to check how that object behaves. Let me simplify that code:</p>class FooTest { private static final String MSG = "something"; @Before public final void setUp() throws Exception { this.foo = new Foo(FooTest.MSG); } @Test public void simplyWorks() throws IOException { assertThat( foo.doSomething(), containsString(FooTest.MSG) ); } @Test public void simplyWorksAgain() throws IOException { assertThat( foo.doSomethingElse(), containsString(FooTest.MSG) ); } }</pre>VerboseListTest and it’s very wrong. Why? Because this shared literal MSG introduced an unnatural coupling between these two test methods. They have nothing in common, because they test different behaviors of class Foo. But this private constant ties them together. Now they are somehow related.</p><p>If and when I want to modify one of the test methods, I may need to modify the other one too. Say I want to see how doSomethingElse() behaves if the encapsulated message is an empty string. What do I do? I change the value of the constant FooTest.MSG, which is used by another test method. This is called coupling. And it’s a bad thing.</p><p>What do we do? Well, we can use that "something" string literal in both test methods:</p>class FooTest { @Test public void simplyWorks() throws IOException { assertThat( new Foo("something").doSomething(), containsString("something") ); } @Test public void simplyWorksAgain() throws IOException { assertThat( new Foo("something").doSomethingElse(), containsString("something") ); } }</pre>setUp() method and the private static literal MSG. What do we have now? Code duplication. String "something" shows up four times in the test class. No static analyzers will tolerate that. Moreover, there are seven (!) test methods in VerboseListTest, which are using MSG. Thus, we will have 14 occurrences of "something", right? Yes, that’s right and that’s most likely why one of authors of this test case introduced the constant—to get rid of duplication. BTW, @Happy-Neko did that in pull request #513, @carlosmiranda reviewed the code and I approved the changes. So, three people made/approved that mistake, including myself.</p><p>So what is the right approach that will avoid code duplication and at the same time won’t introduce coupling? Here it is:</p>class FooTest { @Test public void simplyWorks() throws IOException { final String msg = "something"; assertThat( new Foo(msg).doSomething(), containsString(msg) ); } @Test public void simplyWorksAgain() throws IOException { final String msg = "something else"; assertThat( new Foo(msg).doSomethingElse(), containsString(msg) ); } }</pre>"something" in so many places. It questions us—why are they the same? Is it really so important to use "something" everywhere? Why can’t you use different literals? Of course we can. And we should.</p><p>The bottom line is that each test method must have its own set of data and objects. They must not be shared between test methods ever. Test methods must always be independent, having nothing in common.</p><p>Having that in mind, we can easily conclude that methods like setUp() or any shared variables in test classes are evil. They must not be used and simply must not exist. I think that their invention in JUnit caused a lot of harm to Java code.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>12 Best</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>All 292</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Webinars</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Talks</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Books</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Papers</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Pets</li> <li /2016/04/26/why-inputstream-design-is-wrong.html class=”highlighted”>Trainings</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Award</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Testimonials</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Shift-M</li> <li /2016/04/26/why-inputstream-design-is-wrong.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/04/26/why-inputstream-design-is-wrong.html</p><h1 itemprop="name headline mainEntityOfPage">Why InputStream Design Is Wrong</h1><aside class='book'>
Read more about this subject in Section 2.9of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Washington, D.C.</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>It’s not just about InputSteam, this class is a good example of a bad design. I’m talking about three overloaded methods read(). I’ve mentioned this problem in Section 2.9 of Elegant Objects. In a few words, I strongly believe that interfaces must be “functionality poor.” InputStream should have been an interface in the first place and it should have had a single method read(byte[]). Then if its authors wanted to give us extra functionality, they should have created supplementary “smart” classes.</p>
<figcaption id="490f983a">A Serious Man (2009) by Coen Brothers</figcaption>abstract class InputStream { int read(); int read(byte[] buffer, int offset, int length); int read(byte[] buffer); }</pre>
<div class="play"></div></div><div>Smart Classes and Functionality-Poor Interfaces (webinar #16); 7 July 2016.</div></aside><p>However, we are still lacking a few methods: for reading the bytes and immediately saving into a file, converting to a text with a selected encoding, sending them by email and posting on Twitter. It would be great to have the features too, right in the poor InputStream. I hope the Oracle Java team is working on them now.</p><p>In the mean time, let’s see what exactly is wrong with what these bright engineers designed for us already. Or maybe let me show how I would design InputStream and we’ll compare:</p>interface InputStream { int read(byte[] buffer, int offset, int length); }</pre>InputStream is responsible for reading bytes from the stream. There is one single method for this feature. Is it convenient for everybody? Does it read and post on Twitter? Not yet. Do we need that functionality? Of course we do, but it doesn’t mean that we will add it to the interface. Instead, we will create supplementary “smart” class:</p>interface InputStream { int read(byte[] buffer, int offset, int length); class Smart { private final InputStream origin; public Smart(InputStream stream) { this.origin = stream; } public int read() { final byte[] buffer = new byte[1]; final int read = this.origin.read(buffer, 0, 1); final int result; if (read < 1) { result = -1; } else { result = buffer[0]; } return result; } } }</pre>final InputStream input = new FileInputStream("/tmp/a.txt"); final byte b = new InputStream.Smart(input).read();</pre>InputStream, because this is not its business. The stream doesn’t need to know how to manage the data after it is read. All the stream is responsible for is reading, not parsing or manipulating afterwards.</p><p>Interfaces must be small.</p><p>Obviously, method overloading in interfaces is a code smell. An interface with more than three methods is a good candidate for refactoring. If methods overload each other—it’s serious trouble.</p><p>Interfaces must be small!</p><p>You may say that the creators of InputStream cared about performance, that’s why allowed us to implement read() in three different forms. Then I have to ask again, why not create a method for reading and immediately post it on Twitter? That would be fantastically fast. Isn’t it what we all want? A fast software which nobody has any desire to read or maintain.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>It’s not just about InputSteam, this class is a good example of a bad design. I’m talking about three overloaded methods read(). I’ve mentioned this problem in Section 2.9 of Elegant Objects. In a few words, I strongly believe that interfaces must be “functionality poor.” InputStream should have been an interface in the first place and it should have had a single method read(byte[]). Then if its authors wanted to give us extra functionality, they should have created supplementary “smart” classes.</p><figcaption id="490f983a">A Serious Man (2009) by Coen Brothers</figcaption>abstract class InputStream { int read(); int read(byte[] buffer, int offset, int length); int read(byte[] buffer); }</pre><div class="play"></div></div><div>Smart Classes and Functionality-Poor Interfaces (webinar #16); 7 July 2016.</div></aside><p>However, we are still lacking a few methods: for reading the bytes and immediately saving into a file, converting to a text with a selected encoding, sending them by email and posting on Twitter. It would be great to have the features too, right in the poor InputStream. I hope the Oracle Java team is working on them now.</p><p>In the mean time, let’s see what exactly is wrong with what these bright engineers designed for us already. Or maybe let me show how I would design InputStream and we’ll compare:</p>interface InputStream { int read(byte[] buffer, int offset, int length); }</pre>InputStream is responsible for reading bytes from the stream. There is one single method for this feature. Is it convenient for everybody? Does it read and post on Twitter? Not yet. Do we need that functionality? Of course we do, but it doesn’t mean that we will add it to the interface. Instead, we will create supplementary “smart” class:</p>interface InputStream { int read(byte[] buffer, int offset, int length); class Smart { private final InputStream origin; public Smart(InputStream stream) { this.origin = stream; } public int read() { final byte[] buffer = new byte[1]; final int read = this.origin.read(buffer, 0, 1); final int result; if (read < 1) { result = -1; } else { result = buffer[0]; } return result; } } }</pre>final InputStream input = new FileInputStream("/tmp/a.txt"); final byte b = new InputStream.Smart(input).read();</pre>InputStream, because this is not its business. The stream doesn’t need to know how to manage the data after it is read. All the stream is responsible for is reading, not parsing or manipulating afterwards.</p><p>Interfaces must be small.</p><p>Obviously, method overloading in interfaces is a code smell. An interface with more than three methods is a good candidate for refactoring. If methods overload each other—it’s serious trouble.</p><p>Interfaces must be small!</p><p>You may say that the creators of InputStream cared about performance, that’s why allowed us to implement read() in three different forms. Then I have to ask again, why not create a method for reading and immediately post it on Twitter? That would be fantastically fast. Isn’t it what we all want? A fast software which nobody has any desire to read or maintain.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/04/19/object-must-not-be-configurable.html>12 Best</li> <li /2016/04/19/object-must-not-be-configurable.html>All 292</li> <li /2016/04/19/object-must-not-be-configurable.html>Webinars</li> <li /2016/04/19/object-must-not-be-configurable.html>Talks</li> <li /2016/04/19/object-must-not-be-configurable.html>Books</li> <li /2016/04/19/object-must-not-be-configurable.html>Papers</li> <li /2016/04/19/object-must-not-be-configurable.html>Pets</li> <li /2016/04/19/object-must-not-be-configurable.html class=”highlighted”>Trainings</li> <li /2016/04/19/object-must-not-be-configurable.html>Award</li> <li /2016/04/19/object-must-not-be-configurable.html>Testimonials</li> <li /2016/04/19/object-must-not-be-configurable.html>Shift-M</li> <li /2016/04/19/object-must-not-be-configurable.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/04/19/object-must-not-be-configurable.html</p><h1 itemprop="name headline mainEntityOfPage">Object Behavior Must Not Be Configurable</h1><aside class='book'>Read more about this subject in Section 5.5of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">New York, NY</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Using object properties as configuration parameters is a very common mistake we keep making mostly because our objects are mutable—we configure them. We change their behavior by injecting parameters or even entire settings/configuration objects into them. Do I have to say that it’s abusive and disrespectful from a philosophical point of view? I can, but let’s take a look at it from a practical perspective.</p>
<figcaption id="b28b6a76">The Take (2009) by David Drury</figcaption>class Page { private final String uri; Page(final String address) { this.uri = address; } public String html() throws IOException { return IOUtils.toString( new URL(this.uri).openStream(), "UTF-8" ); } }</pre>String html = new Page("http://www.google.com").html();</pre>"UTF-8". We want it to be configurable. Here is what we do:</p>class Page { private final String uri; private final String encoding; Page(final String address, final String enc) { this.uri = address; this.encoding = enc; } public String html() throws IOException { return IOUtils.toString( new URL(this.uri).openStream(), this.encoding ); } }</pre>"<html/>". But not always. We want this to be configurable. Here is what we do:</p>class Page { private final String uri; private final String encoding; private final boolean alwaysHtml; Page(final String address, final String enc, final boolean always) { this.uri = address; this.encoding = enc; this.alwaysHtml = always; } public String html() throws IOException { String html = IOUtils.toString( new URL(this.uri).openStream(), this.encoding ); if (html.isEmpty() && this.alwaysHtml) { html = "<html/>"; } return html; } }</pre>class Page { private final String uri; private final String encoding; private final boolean alwaysHtml; private final boolean encodeAnyway; Page(final String address, final String enc, final boolean always, final boolean encode) { this.uri = address; this.encoding = enc; this.alwaysHtml = always; this.encodeAnyway = encode; } public String html() throws IOException, UnsupportedEncodingException { final byte[] bytes = IOUtils.toByteArray( new URL(this.uri).openStream() ); String html; try { html = new String(bytes, this.encoding); } catch (UnsupportedEncodingException ex) { if (!this.encodeAnyway) { throw ex; } html = new String(bytes, "UTF-8") } if (html.isEmpty() && this.alwaysHtml) { html = "<html/>"; } return html; } }</pre>PageSettings:</p>class Page { private final String uri; private final PageSettings settings; Page(final String address, final PageSettings stts) { this.uri = address; this.settings = stts; } public String html() throws IOException { final byte[] bytes = IOUtils.toByteArray( new URL(this.uri).openStream() ); String html; try { html = new String(bytes, this.settings.getEncoding()); } catch (UnsupportedEncodingException ex) { if (!this.settings.isEncodeAnyway()) { throw ex; } html = new String(bytes, "UTF-8") } if (html.isEmpty() && this.settings.isAlwaysHtml()) { html = "<html/>"; } return html; } }</pre>PageSettings is basically a holder of parameters, without any behavior. It has getters, which give us access to the parameters: isEncodeAnyway(), isAlwaysHtml(), and getEncoding(). If we keep going in this direction, there could be a few dozen configuration settings in that class. This may look very convenient and is a very typical pattern in Java world. For example, look at JobConf from Hadoop. This is how we will call our highly configurable Page (I’m assuming PageSettings is immutable):</p>String html = new Page( "http://www.google.com", new PageSettings() .withEncoding("ISO_8859_1") .withAlwaysHtml(true) .withEncodeAnyway(false) ).html();</pre>uri is the coordinate, while the alwaysHtml boolean property is a behavior changing trigger. See the difference?</p><p>So, what should we do instead? What is the right design? We must use composable decorators. Here is how:</p>Page page = new NeverEmptyPage( new DefaultPage("http://www.google.com") ) String html = new AlwaysTextPage( new TextPage(page, "ISO_8859_1") page ).html();</pre>DefaultPage would look (yes, I had to change its design a bit):</p>class DefaultPage implements Page { private final String uri; DefaultPage(final String address) { this.uri = address; } @Override public byte[] html() throws IOException { return IOUtils.toByteArray( new URL(this.uri).openStream() ); } }</pre>Page. Now TextPage decorator, which converts an array of bytes to a text using provided encoding:</p>class TextPage { private final Page origin; private final String encoding; TextPage(final Page page, final String enc) { this.origin = page; this.encoding = enc; } public String html() throws IOException { return new String( this.origin.html(), this.encoding ); } }</pre>NeverEmptyPage:</p>class NeverEmptyPage implements Page { private final Page origin; NeverEmptyPage(final Page page) { this.origin = page; } @Override public byte[] html() throws IOException { byte[] bytes = this.origin.html(); if (bytes.length == 0) { bytes = "<html/>".getBytes(); } return bytes; } }</pre>AlwaysTextPage:</p>class AlwaysTextPage { private final TextPage origin; private final Page source; AlwaysTextPage(final TextPage page, final Page src) { this.origin = page; this.source = src; } public String html() throws IOException { String html; try { html = this.origin.html(); } catch (UnsupportedEncodingException ex) { html = new TextPage(this.source, "UTF-8").html(); } return html; } }</pre>AlwaysTextPage will make two calls to the encapsulated origin, in case of an unsupported encoding, which will lead to a duplicated HTTP request. That’s true and this is by design. We don’t want this duplicated HTTP roundtrip to happen. Let’s introduce one more class, which will cache the page fetched ( not thread-safe, but it’s not important now):</p>class OncePage implements Page { private final Page origin; private final AtomicReference<byte[]> cache = new AtomicReference<>; OncePage(final Page page) { this.origin = page; } @Override public byte[] html() throws IOException { if (this.cache.get() == null) { this.cache.set(this.origin.html()); } return this.cache.get(); } }</pre>OncePage):</p>Page page = new NeverEmptyPage( new OncePage( new DefaultPage("http://www.google.com") ) ) String html = new AlwaysTextPage( new TextPage(page, "ISO_8859_1") "UTF-8" ).html();</pre><figcaption id="b28b6a76">The Take (2009) by David Drury</figcaption>class Page { private final String uri; Page(final String address) { this.uri = address; } public String html() throws IOException { return IOUtils.toString( new URL(this.uri).openStream(), "UTF-8" ); } }</pre>String html = new Page("http://www.google.com").html();</pre>"UTF-8". We want it to be configurable. Here is what we do:</p>class Page { private final String uri; private final String encoding; Page(final String address, final String enc) { this.uri = address; this.encoding = enc; } public String html() throws IOException { return IOUtils.toString( new URL(this.uri).openStream(), this.encoding ); } }</pre>"<html/>". But not always. We want this to be configurable. Here is what we do:</p>class Page { private final String uri; private final String encoding; private final boolean alwaysHtml; Page(final String address, final String enc, final boolean always) { this.uri = address; this.encoding = enc; this.alwaysHtml = always; } public String html() throws IOException { String html = IOUtils.toString( new URL(this.uri).openStream(), this.encoding ); if (html.isEmpty() && this.alwaysHtml) { html = "<html/>"; } return html; } }</pre>class Page { private final String uri; private final String encoding; private final boolean alwaysHtml; private final boolean encodeAnyway; Page(final String address, final String enc, final boolean always, final boolean encode) { this.uri = address; this.encoding = enc; this.alwaysHtml = always; this.encodeAnyway = encode; } public String html() throws IOException, UnsupportedEncodingException { final byte[] bytes = IOUtils.toByteArray( new URL(this.uri).openStream() ); String html; try { html = new String(bytes, this.encoding); } catch (UnsupportedEncodingException ex) { if (!this.encodeAnyway) { throw ex; } html = new String(bytes, "UTF-8") } if (html.isEmpty() && this.alwaysHtml) { html = "<html/>"; } return html; } }</pre>PageSettings:</p>class Page { private final String uri; private final PageSettings settings; Page(final String address, final PageSettings stts) { this.uri = address; this.settings = stts; } public String html() throws IOException { final byte[] bytes = IOUtils.toByteArray( new URL(this.uri).openStream() ); String html; try { html = new String(bytes, this.settings.getEncoding()); } catch (UnsupportedEncodingException ex) { if (!this.settings.isEncodeAnyway()) { throw ex; } html = new String(bytes, "UTF-8") } if (html.isEmpty() && this.settings.isAlwaysHtml()) { html = "<html/>"; } return html; } }</pre>PageSettings is basically a holder of parameters, without any behavior. It has getters, which give us access to the parameters: isEncodeAnyway(), isAlwaysHtml(), and getEncoding(). If we keep going in this direction, there could be a few dozen configuration settings in that class. This may look very convenient and is a very typical pattern in Java world. For example, look at JobConf from Hadoop. This is how we will call our highly configurable Page (I’m assuming PageSettings is immutable):</p>String html = new Page( "http://www.google.com", new PageSettings() .withEncoding("ISO_8859_1") .withAlwaysHtml(true) .withEncodeAnyway(false) ).html();</pre>uri is the coordinate, while the alwaysHtml boolean property is a behavior changing trigger. See the difference?</p><p>So, what should we do instead? What is the right design? We must use composable decorators. Here is how:</p>Page page = new NeverEmptyPage( new DefaultPage("http://www.google.com") ) String html = new AlwaysTextPage( new TextPage(page, "ISO_8859_1") page ).html();</pre>DefaultPage would look (yes, I had to change its design a bit):</p>class DefaultPage implements Page { private final String uri; DefaultPage(final String address) { this.uri = address; } @Override public byte[] html() throws IOException { return IOUtils.toByteArray( new URL(this.uri).openStream() ); } }</pre>Page. Now TextPage decorator, which converts an array of bytes to a text using provided encoding:</p>class TextPage { private final Page origin; private final String encoding; TextPage(final Page page, final String enc) { this.origin = page; this.encoding = enc; } public String html() throws IOException { return new String( this.origin.html(), this.encoding ); } }</pre>NeverEmptyPage:</p>class NeverEmptyPage implements Page { private final Page origin; NeverEmptyPage(final Page page) { this.origin = page; } @Override public byte[] html() throws IOException { byte[] bytes = this.origin.html(); if (bytes.length == 0) { bytes = "<html/>".getBytes(); } return bytes; } }</pre>AlwaysTextPage:</p>class AlwaysTextPage { private final TextPage origin; private final Page source; AlwaysTextPage(final TextPage page, final Page src) { this.origin = page; this.source = src; } public String html() throws IOException { String html; try { html = this.origin.html(); } catch (UnsupportedEncodingException ex) { html = new TextPage(this.source, "UTF-8").html(); } return html; } }</pre>AlwaysTextPage will make two calls to the encapsulated origin, in case of an unsupported encoding, which will lead to a duplicated HTTP request. That’s true and this is by design. We don’t want this duplicated HTTP roundtrip to happen. Let’s introduce one more class, which will cache the page fetched ( not thread-safe, but it’s not important now):</p>class OncePage implements Page { private final Page origin; private final AtomicReference<byte[]> cache = new AtomicReference<>; OncePage(final Page page) { this.origin = page; } @Override public byte[] html() throws IOException { if (this.cache.get() == null) { this.cache.set(this.origin.html()); } return this.cache.get(); } }</pre>OncePage):</p>Page page = new NeverEmptyPage( new OncePage( new DefaultPage("http://www.google.com") ) ) String html = new AlwaysTextPage( new TextPage(page, "ISO_8859_1") "UTF-8" ).html();</pre> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/04/12/java-annotations-are-evil.html>12 Best</li> <li /2016/04/12/java-annotations-are-evil.html>All 292</li> <li /2016/04/12/java-annotations-are-evil.html>Webinars</li> <li /2016/04/12/java-annotations-are-evil.html>Talks</li> <li /2016/04/12/java-annotations-are-evil.html>Books</li> <li /2016/04/12/java-annotations-are-evil.html>Papers</li> <li /2016/04/12/java-annotations-are-evil.html>Pets</li> <li /2016/04/12/java-annotations-are-evil.html class=”highlighted”>Trainings</li> <li /2016/04/12/java-annotations-are-evil.html>Award</li> <li /2016/04/12/java-annotations-are-evil.html>Testimonials</li> <li /2016/04/12/java-annotations-are-evil.html>Shift-M</li> <li /2016/04/12/java-annotations-are-evil.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/04/12/java-annotations-are-evil.html</p><h1 itemprop="name headline mainEntityOfPage">Java Annotations Are a Big Mistake</h1><aside class='book'>Read more about this subject in Section 6.1of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Seattle, WA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Annotations were introduced in Java 5, and we all got excited. Such a great instrument to make code shorter! No more Hibernate/Spring XML configuration files! Just annotations, right there in the code where we need them. No more marker interfaces, just a runtime-retained reflection-discoverable annotation! I was excited too. Moreover, I’ve made a few open source libraries which use annotations heavily. Take jcabi-aspects, for example. However, I’m not excited any more. Moreover, I believe that annotations are a big mistake in Java design.</p>
<figcaption id="8ef9c86b">Gomorra (2008) by Matteo Garrone)</figcaption>
<div class="play"></div></div><div>Java Annotations Are a Big Mistake (webinar #14); 4 May 2016.</div></aside><p>Long story short, there is one big problem with annotations—they encourage us to implement object functionality outside of an object, which is against the very principle of encapsulation. The object is not solid any more, since its behavior is not defined entirely by its own methods—some of its functionality stays elsewhere. Why is it bad? Let’s see in a few examples.</p><h2 id="inject">@Inject</h2><p>Say we annotate a property with @Inject:</p>import javax.inject.Inject; public class Books { @Inject private final DB db; // some methods here, which use this.db }</pre>Injector injector = Guice.createInjector( new AbstractModule() { @Override public void configure() { this.bind(DB.class).toInstance( new Postgres("jdbc:postgresql:5740/main") ); } } );</pre>Books via the container:</p>Books books = injector.getInstance(Books.class);</pre>Books has no idea how and who will inject an instance of class DB into it. This will happen behind the scenes and outside of its control. The injection will do it. It may look convenient, but this attitude causes a lot of damage to the entire code base. The control is lost (not inverted, but lost!). The object is not in charge any more. It can’t be responsible for what’s happening to it.</p><p>Instead, here is how this should be done:</p>class Books { private final DB db; Books(final DB base) { this.db = base; } // some methods here, which use this.db }</pre>@XmlElement</h2><aside class="youtube"> <div class="box"> 
<div class="play"></div></div><div>Dependency Injection Container is a Bad Idea (webinar #9); 1 December 2015.</div></aside><p>This is how JAXB works, when you want to convert your POJO to XML. First, you attach the @XmlElement annotation to the getter:</p>import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement public class Book { private final String title; public Book(final String title) { this.title = title; } @XmlElement public String getTitle() { return this.title; } }</pre>Book into XML:</p>final Book book = new Book("0132350882", "Clean Code"); final JAXBContext ctx = JAXBContext.newInstance(Book.class); final Marshaller marshaller = ctx.createMarshaller(); marshaller.marshal(book, System.out);</pre>
<div class="play"></div></div><div>Java Annotations Are a Bad Idea; 20 June 2017.</div></aside><p>Who is creating the XML? Not the book. Someone else, outside of the class Book. This is very wrong. Instead, this is how this should have been done. First, the class that has no idea about XML:</p>class DefaultBook implements Book { private final String title; DefaultBook(final String title) { this.title = title; } @Override public String getTitle() { return this.title; } }</pre>class XmlBook implements Book{ private final Book origin; XmlBook(final Book book) { this.origin = book; } @Override public String getTitle() { return this.origin.getTitle(); } public String toXML() { return String.format( "<book><title>%s</title></book>", this.getTitle() ); } }</pre>String xml = new XmlBook( new DefaultBook("Elegant Objects") ).toXML();</pre>XmlBook. If you don’t like the decorator idea, you can move the toXML() method to the DefaultBook class. It’s not important. What is important is that the functionality always stays where it belongs—inside the object. Only the object knows how to print itself to the XML. Nobody else!</p><h2 id="retryonfailure">@RetryOnFailure</h2><p>Here is an example (from my own library):</p>import com.jcabi.aspects.RetryOnFailure; class Foo { @RetryOnFailure public String load(URL url) { return url.openConnection().getContent(); } }</pre>class Foo { public String load(URL url) { while (true) { try { return _Foo.load(url); } catch (Exception ex) { // ignore it } } } class _Foo { public String load(URL url) { return url.openConnection().getContent(); } } }</pre>@RetryOnFailure annotation as a signal, informing us that the class has to be wrapped into another one. This is happening behind the scenes. We don’t see that supplementary class, which implements the retrying algorithm. But the bytecode produced by the AspectJ weaver contains a modified version of class Foo.</p><aside class="youtube"> <div class="box"> 
<div class="play"></div></div><div>Why Getters-and-Setters Is An Anti-Pattern? (webinar #4); 1 July 2015.</div></aside><p>That is exactly what is wrong with this approach—we don’t see and don’t control the instantiation of that supplementary object. Object composition, which is the most important process in object design, is hidden somewhere behind the scenes. You may say that we don’t need to see it since it’s supplementary. I disagree. We must see how our objects are composed. We may not care about how they work, but we must see the entire composition process.</p><p>A much better design would look like this (instead of annotations):</p>Foo foo = new FooThatRetries(new Foo());</pre>FooThatRetries:</p>class FooThatRetries implements Foo { private final Foo origin; FooThatRetries(Foo foo) { this.origin = foo; } public String load(URL url) { return new Retry().eval( new Retry.Algorithm<String>() { @Override public String eval() { return FooThatRetries.this.load(url); } } ); } }</pre>Retry:</p>class Retry { public <T> T eval(Retry.Algorithm<T> algo) { while (true) { try { return algo.eval(); } catch (Exception ex) { // ignore it } } } interface Algorithm<T> { T eval(); } }</pre>new. This operator is the key instrument for an OOP developer. Taking it away from us and giving us “configuration mechanisms” is an unforgivable crime.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Annotations were introduced in Java 5, and we all got excited. Such a great instrument to make code shorter! No more Hibernate/Spring XML configuration files! Just annotations, right there in the code where we need them. No more marker interfaces, just a runtime-retained reflection-discoverable annotation! I was excited too. Moreover, I’ve made a few open source libraries which use annotations heavily. Take jcabi-aspects, for example. However, I’m not excited any more. Moreover, I believe that annotations are a big mistake in Java design.</p><figcaption id="8ef9c86b">Gomorra (2008) by Matteo Garrone)</figcaption><div class="play"></div></div><div>Java Annotations Are a Big Mistake (webinar #14); 4 May 2016.</div></aside><p>Long story short, there is one big problem with annotations—they encourage us to implement object functionality outside of an object, which is against the very principle of encapsulation. The object is not solid any more, since its behavior is not defined entirely by its own methods—some of its functionality stays elsewhere. Why is it bad? Let’s see in a few examples.</p><h2 id="inject">@Inject</h2><p>Say we annotate a property with @Inject:</p>import javax.inject.Inject; public class Books { @Inject private final DB db; // some methods here, which use this.db }</pre>Injector injector = Guice.createInjector( new AbstractModule() { @Override public void configure() { this.bind(DB.class).toInstance( new Postgres("jdbc:postgresql:5740/main") ); } } );</pre>Books via the container:</p>Books books = injector.getInstance(Books.class);</pre>Books has no idea how and who will inject an instance of class DB into it. This will happen behind the scenes and outside of its control. The injection will do it. It may look convenient, but this attitude causes a lot of damage to the entire code base. The control is lost (not inverted, but lost!). The object is not in charge any more. It can’t be responsible for what’s happening to it.</p><p>Instead, here is how this should be done:</p>class Books { private final DB db; Books(final DB base) { this.db = base; } // some methods here, which use this.db }</pre>@XmlElement</h2><aside class="youtube"> <div class="box"> <div class="play"></div></div><div>Dependency Injection Container is a Bad Idea (webinar #9); 1 December 2015.</div></aside><p>This is how JAXB works, when you want to convert your POJO to XML. First, you attach the @XmlElement annotation to the getter:</p>import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement public class Book { private final String title; public Book(final String title) { this.title = title; } @XmlElement public String getTitle() { return this.title; } }</pre>Book into XML:</p>final Book book = new Book("0132350882", "Clean Code"); final JAXBContext ctx = JAXBContext.newInstance(Book.class); final Marshaller marshaller = ctx.createMarshaller(); marshaller.marshal(book, System.out);</pre><div class="play"></div></div><div>Java Annotations Are a Bad Idea; 20 June 2017.</div></aside><p>Who is creating the XML? Not the book. Someone else, outside of the class Book. This is very wrong. Instead, this is how this should have been done. First, the class that has no idea about XML:</p>class DefaultBook implements Book { private final String title; DefaultBook(final String title) { this.title = title; } @Override public String getTitle() { return this.title; } }</pre>class XmlBook implements Book{ private final Book origin; XmlBook(final Book book) { this.origin = book; } @Override public String getTitle() { return this.origin.getTitle(); } public String toXML() { return String.format( "<book><title>%s</title></book>", this.getTitle() ); } }</pre>String xml = new XmlBook( new DefaultBook("Elegant Objects") ).toXML();</pre>XmlBook. If you don’t like the decorator idea, you can move the toXML() method to the DefaultBook class. It’s not important. What is important is that the functionality always stays where it belongs—inside the object. Only the object knows how to print itself to the XML. Nobody else!</p><h2 id="retryonfailure">@RetryOnFailure</h2><p>Here is an example (from my own library):</p>import com.jcabi.aspects.RetryOnFailure; class Foo { @RetryOnFailure public String load(URL url) { return url.openConnection().getContent(); } }</pre>class Foo { public String load(URL url) { while (true) { try { return _Foo.load(url); } catch (Exception ex) { // ignore it } } } class _Foo { public String load(URL url) { return url.openConnection().getContent(); } } }</pre>@RetryOnFailure annotation as a signal, informing us that the class has to be wrapped into another one. This is happening behind the scenes. We don’t see that supplementary class, which implements the retrying algorithm. But the bytecode produced by the AspectJ weaver contains a modified version of class Foo.</p><aside class="youtube"> <div class="box"> <div class="play"></div></div><div>Why Getters-and-Setters Is An Anti-Pattern? (webinar #4); 1 July 2015.</div></aside><p>That is exactly what is wrong with this approach—we don’t see and don’t control the instantiation of that supplementary object. Object composition, which is the most important process in object design, is hidden somewhere behind the scenes. You may say that we don’t need to see it since it’s supplementary. I disagree. We must see how our objects are composed. We may not care about how they work, but we must see the entire composition process.</p><p>A much better design would look like this (instead of annotations):</p>Foo foo = new FooThatRetries(new Foo());</pre>FooThatRetries:</p>class FooThatRetries implements Foo { private final Foo origin; FooThatRetries(Foo foo) { this.origin = foo; } public String load(URL url) { return new Retry().eval( new Retry.Algorithm<String>() { @Override public String eval() { return FooThatRetries.this.load(url); } } ); } }</pre>Retry:</p>class Retry { public <T> T eval(Retry.Algorithm<T> algo) { while (true) { try { return algo.eval(); } catch (Exception ex) { // ignore it } } } interface Algorithm<T> { T eval(); } }</pre>new. This operator is the key instrument for an OOP developer. Taking it away from us and giving us “configuration mechanisms” is an unforgivable crime.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/04/05/printers-instead-of-getters.html>12 Best</li> <li /2016/04/05/printers-instead-of-getters.html>All 292</li> <li /2016/04/05/printers-instead-of-getters.html>Webinars</li> <li /2016/04/05/printers-instead-of-getters.html>Talks</li> <li /2016/04/05/printers-instead-of-getters.html>Books</li> <li /2016/04/05/printers-instead-of-getters.html>Papers</li> <li /2016/04/05/printers-instead-of-getters.html>Pets</li> <li /2016/04/05/printers-instead-of-getters.html class=”highlighted”>Trainings</li> <li /2016/04/05/printers-instead-of-getters.html>Award</li> <li /2016/04/05/printers-instead-of-getters.html>Testimonials</li> <li /2016/04/05/printers-instead-of-getters.html>Shift-M</li> <li /2016/04/05/printers-instead-of-getters.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/04/05/printers-instead-of-getters.html</p><h1 itemprop="name headline mainEntityOfPage">Printers Instead of Getters</h1><aside class='book'>Read more about this subject in Section 5.3of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Palo Alto, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Getters and setters are evil. No need to argue about this, it’s settled. You disagree? Let’s discuss that later. For now, let’s say, we want to get rid of getters. The key question is how is it possible at all? We do need to get the data out of an object, right? Nope. Wrong.</p>
<figcaption id="a123a2ca">Le fabuleux destin d'Amélie Poulain (2001) by Jean-Pierre Jeunet</figcaption>public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; }</pre>import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; @XmlElement public String getIsbn() { return this.isbn; } @XmlElement public String getTitle() { return this.title; } }</pre>
<div class="play"></div></div><div>Printers Instead of Getters in OOP (webinar #18); 7 September 2016.</div></aside><p>This is not because they are so effective. This is because we’re so procedural in our way of thinking. We don’t trust our objects. We only trust the data they store. We don’t want this Book object to generate the XML. We want it to give us the data. We will build the XML. The Book is too stupid to do that job. We’re way smarter!</p><p>I’m suggesting to stop thinking this way. Instead, let’s try to give this poor Book a chance, and equip it with a “printer”:</p>public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; public String toXML() { return String.format( "<book><isbn>%s</isbn><title>%s</title></book>", this.isbn, this.title ); } }</pre>public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; public String toJSON() { return String.format( "{\"isbn\":\"%s\", \"title\":\"%s\"}", this.isbn, this.title ); } }</pre>public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; public Media print(Media media) { return media .with("isbn", this.isbn) .with("title", this.title); } }</pre>Media class, but you got the idea—the media accepts the data. Now, we want to print our object to JSON (this design is not really perfect, since JsonObjectBuilder is not immutable, even though it looks like one…):</p>class JsonMedia implements Media { private final JsonObjectBuilder builder; JsonMedia() { this("book"); } JsonMedia(String head) { this(Json.createObjectBuilder().add(head)); } JsonMedia(JsonObjectBuilder bdr) { this.builder = bdr; } @Override public Media with(String name, String value) { return new JsonMedia( this.builder.add(name, value) ); } public JsonObject json() { return this.builder.build(); } }</pre>JsonMedia and ask our book to print itself there:</p>JsonMedia media = new JsonMedia("book"); book.print(media); JsonObject json = media.json();</pre>XmlMedia, which will print the book to XML. The Book class stays small, while the complexity of “media” objects is unlimited.</p><p>My point here is simple—no getters, just printers!</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Getters and setters are evil. No need to argue about this, it’s settled. You disagree? Let’s discuss that later. For now, let’s say, we want to get rid of getters. The key question is how is it possible at all? We do need to get the data out of an object, right? Nope. Wrong.</p><figcaption id="a123a2ca">Le fabuleux destin d'Amélie Poulain (2001) by Jean-Pierre Jeunet</figcaption>public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; }</pre>import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; @XmlElement public String getIsbn() { return this.isbn; } @XmlElement public String getTitle() { return this.title; } }</pre><div class="play"></div></div><div>Printers Instead of Getters in OOP (webinar #18); 7 September 2016.</div></aside><p>This is not because they are so effective. This is because we’re so procedural in our way of thinking. We don’t trust our objects. We only trust the data they store. We don’t want this Book object to generate the XML. We want it to give us the data. We will build the XML. The Book is too stupid to do that job. We’re way smarter!</p><p>I’m suggesting to stop thinking this way. Instead, let’s try to give this poor Book a chance, and equip it with a “printer”:</p>public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; public String toXML() { return String.format( "<book><isbn>%s</isbn><title>%s</title></book>", this.isbn, this.title ); } }</pre>public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; public String toJSON() { return String.format( "{\"isbn\":\"%s\", \"title\":\"%s\"}", this.isbn, this.title ); } }</pre>public class Book { private final String isbn = "0735619654"; private final String title = "Object Thinking"; public Media print(Media media) { return media .with("isbn", this.isbn) .with("title", this.title); } }</pre>Media class, but you got the idea—the media accepts the data. Now, we want to print our object to JSON (this design is not really perfect, since JsonObjectBuilder is not immutable, even though it looks like one…):</p>class JsonMedia implements Media { private final JsonObjectBuilder builder; JsonMedia() { this("book"); } JsonMedia(String head) { this(Json.createObjectBuilder().add(head)); } JsonMedia(JsonObjectBuilder bdr) { this.builder = bdr; } @Override public Media with(String name, String value) { return new JsonMedia( this.builder.add(name, value) ); } public JsonObject json() { return this.builder.build(); } }</pre>JsonMedia and ask our book to print itself there:</p>JsonMedia media = new JsonMedia("book"); book.print(media); JsonObject json = media.json();</pre>XmlMedia, which will print the book to XML. The Book class stays small, while the complexity of “media” objects is unlimited.</p><p>My point here is simple—no getters, just printers!</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/03/22/try-finally-if-not-null.html>12 Best</li> <li /2016/03/22/try-finally-if-not-null.html>All 292</li> <li /2016/03/22/try-finally-if-not-null.html>Webinars</li> <li /2016/03/22/try-finally-if-not-null.html>Talks</li> <li /2016/03/22/try-finally-if-not-null.html>Books</li> <li /2016/03/22/try-finally-if-not-null.html>Papers</li> <li /2016/03/22/try-finally-if-not-null.html>Pets</li> <li /2016/03/22/try-finally-if-not-null.html class=”highlighted”>Trainings</li> <li /2016/03/22/try-finally-if-not-null.html>Award</li> <li /2016/03/22/try-finally-if-not-null.html>Testimonials</li> <li /2016/03/22/try-finally-if-not-null.html>Shift-M</li> <li /2016/03/22/try-finally-if-not-null.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/03/22/try-finally-if-not-null.html</p><h1 itemprop="name headline mainEntityOfPage">Try. Finally. If. Not. Null.</h1><aside class='book'>Read more about this subject in Section 2.6of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Palo Alto, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>There is a very typical mistake in pre-Java7 “try/finally” scenario, which I keep seeing in so many code reviews. I just have to write about it. Java7 introduced a solution, but it doesn’t cover all situations. Sometimes we need to deal with non-AutoCloseable resources. Let’s open and close them correctly, please.</p>
<figcaption id="118d4d8e">Lock, Stock and Two Smoking Barrels (1998) by Guy Ritchie</figcaption>InputStream input = null; try { input = url.openStream(); // reads the stream, throws IOException } catch (IOException ex) { throw new RuntimeException(ex); } finally { if (input != null) { input.close(); } }</pre>
<div class="play"></div></div><div>What is Wrong About NULL in OOP? (webinar #3); 3 June 2015.</div></aside><p>I already wrote about null and its evil nature. Here it comes again. If you just follow the rule of “not using NULL anywhere ever,” this code would need an immediate refactoring. Its correct version will look like this:</p>final InputStream input = url.openStream(); try { // reads the stream, throws IOException } catch (IOException ex) { throw new RuntimeException(ex); } finally { input.close(); }</pre>null anymore and it’s very clean. Isn’t it?</p><p>There are situations when opening the resource itself throws IOException and we can’t put it outside of try/catch. In that case, we have to have two try/catch blocks:</p>final InputStream input; try { input = url.openStream(); } catch (IOException ex) { throw new RuntimeException(ex); } try { // reads the stream, throws IOException } catch (IOException ex) { throw new RuntimeException(ex); } finally { input.close(); }</pre>null, never!</p><p>The presence of null in Java code is a clear indicator of code smell. Something is not right if you have to use null. The only place where the presence of null is justified is where we’re using third-party APIs or JDK. They may return null sometimes because… well, their design is bad. We have no other option but to do if(x==null). But that’s it. No other places are good for null.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>There is a very typical mistake in pre-Java7 “try/finally” scenario, which I keep seeing in so many code reviews. I just have to write about it. Java7 introduced a solution, but it doesn’t cover all situations. Sometimes we need to deal with non-AutoCloseable resources. Let’s open and close them correctly, please.</p><figcaption id="118d4d8e">Lock, Stock and Two Smoking Barrels (1998) by Guy Ritchie</figcaption>InputStream input = null; try { input = url.openStream(); // reads the stream, throws IOException } catch (IOException ex) { throw new RuntimeException(ex); } finally { if (input != null) { input.close(); } }</pre><div class="play"></div></div><div>What is Wrong About NULL in OOP? (webinar #3); 3 June 2015.</div></aside><p>I already wrote about null and its evil nature. Here it comes again. If you just follow the rule of “not using NULL anywhere ever,” this code would need an immediate refactoring. Its correct version will look like this:</p>final InputStream input = url.openStream(); try { // reads the stream, throws IOException } catch (IOException ex) { throw new RuntimeException(ex); } finally { input.close(); }</pre>null anymore and it’s very clean. Isn’t it?</p><p>There are situations when opening the resource itself throws IOException and we can’t put it outside of try/catch. In that case, we have to have two try/catch blocks:</p>final InputStream input; try { input = url.openStream(); } catch (IOException ex) { throw new RuntimeException(ex); } try { // reads the stream, throws IOException } catch (IOException ex) { throw new RuntimeException(ex); } finally { input.close(); }</pre>null, never!</p><p>The presence of null in Java code is a clear indicator of code smell. Something is not right if you have to use null. The only place where the presence of null is justified is where we’re using third-party APIs or JDK. They may return null sometimes because… well, their design is bad. We have no other option but to do if(x==null). But that’s it. No other places are good for null.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/02/09/are-you-still-debugging.html>12 Best</li> <li /2016/02/09/are-you-still-debugging.html>All 292</li> <li /2016/02/09/are-you-still-debugging.html>Webinars</li> <li /2016/02/09/are-you-still-debugging.html>Talks</li> <li /2016/02/09/are-you-still-debugging.html>Books</li> <li /2016/02/09/are-you-still-debugging.html>Papers</li> <li /2016/02/09/are-you-still-debugging.html>Pets</li> <li /2016/02/09/are-you-still-debugging.html class=”highlighted”>Trainings</li> <li /2016/02/09/are-you-still-debugging.html>Award</li> <li /2016/02/09/are-you-still-debugging.html>Testimonials</li> <li /2016/02/09/are-you-still-debugging.html>Shift-M</li> <li /2016/02/09/are-you-still-debugging.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/02/09/are-you-still-debugging.html</p><h1 itemprop="name headline mainEntityOfPage">Are You Still Debugging?</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Palo Alto, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="unprintable subline"> <li>Translated:</li> <li>Russian</li> <li>add yours!</li></ul><p class="unprintable"><p>Debugging is “a process of running a program/method interactively, breaking execution flow after each statement and showing…” In a nutshell, it is a very useful technique … for a bad programmer. Or an old programmer who is still writing procedural code in C. Object-oriented programmers never debug their code—they write unit tests. My point here is that unit testing is a technique that completely replaces debugging. If debugging is required, the design is bad.</p>
<figcaption id="867738b9">The Revenant (2015) by Alejandro G. Iñárritu</figcaption>class FileUtils { public static Iterable<String> readWords(File f) { String text = new String( Files.readAllBytes(Paths.get(f)), "UTF-8" ); Set<String> words = new HashSet<>(); for (String word : text.split(" ")) { words.add(word); } return words; } }</pre>We know what we are, but know not what we may be.</pre>"We" "know" "what" "we" "are,\n" "but" "not" "may" "be\n"</pre>
<div class="play"></div></div><div>Unit Testing vs Debugging (webinar #26); 12 July 2017.</div></aside><p>Thus, if you perceive debugging to be faster and easier, think about the quality of your code. I bet it has a lot of opportunities for refactoring, just like the code from the example above. Here is how I would modify it. First of all, I would turn it into a class, because utility static methods are a bad practice:</p>class Words implements Iterable<String> { private final File file; Words(File src) { this.file = src; } @Override public Iterator<String> iterator() { String text = new String( Files.readAllBytes(Paths.get(this.file)), "UTF-8" ); Set<String> words = new HashSet<>(); for (String word : text.split(" ")) { words.add(word); } return words.iterator(); } }</pre>class Text { private final File file; Text(File src) { this.file = src; } @Override public String toString() { return new String( Files.readAllBytes(Paths.get(this.file)), "UTF-8" ); } } class Words implements Iterable<String> { private final String text; Words(String txt) { this.text = txt; } @Override public Iterator<String> iterator() { Set<String> words = new HashSet<>(); for (String word : this.text.split(" ")) { words.add(word); } return words.iterator(); } }</pre>Words class is a pretty trivial task:</p>import org.junit.Test; import static org.hamcrest.MatcherAssert.*; import static org.hamcrest.Matchers.*; public class WordsTest { @Test public void parsesSimpleText() { assertThat( new Words("How are you?"), hasItems("How", "are", "you") ); } }</pre>Words doesn’t do anything with files. It just parses the incoming string and finds the unique words in it. Now it’s easy to fix, since the test is small and we can easily create more tests; for example:</p>import org.junit.Test; import static org.hamcrest.MatcherAssert.*; import static org.hamcrest.Matchers.*; public class WordsTest { @Test public void parsesSimpleText() { assertThat( new Words("How are you?"), hasItems("How", "are", "you") ); } @Test public void parsesMultipleLines() { assertThat( new Words("first line\nsecond line\n"), hasItems("first", "second", "line") ); } }</pre>readWords() (a verb). To the contrary, the second example is about what will be achieved. It’s either the Text of the file or Words of the text (both are nouns).</p><p>I believe there is no place for debugging in clean object-oriented programming. Only unit testing!</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Debugging is “a process of running a program/method interactively, breaking execution flow after each statement and showing…” In a nutshell, it is a very useful technique … for a bad programmer. Or an old programmer who is still writing procedural code in C. Object-oriented programmers never debug their code—they write unit tests. My point here is that unit testing is a technique that completely replaces debugging. If debugging is required, the design is bad.</p><figcaption id="867738b9">The Revenant (2015) by Alejandro G. Iñárritu</figcaption>class FileUtils { public static Iterable<String> readWords(File f) { String text = new String( Files.readAllBytes(Paths.get(f)), "UTF-8" ); Set<String> words = new HashSet<>(); for (String word : text.split(" ")) { words.add(word); } return words; } }</pre>We know what we are, but know not what we may be.</pre>"We" "know" "what" "we" "are,\n" "but" "not" "may" "be\n"</pre><div class="play"></div></div><div>Unit Testing vs Debugging (webinar #26); 12 July 2017.</div></aside><p>Thus, if you perceive debugging to be faster and easier, think about the quality of your code. I bet it has a lot of opportunities for refactoring, just like the code from the example above. Here is how I would modify it. First of all, I would turn it into a class, because utility static methods are a bad practice:</p>class Words implements Iterable<String> { private final File file; Words(File src) { this.file = src; } @Override public Iterator<String> iterator() { String text = new String( Files.readAllBytes(Paths.get(this.file)), "UTF-8" ); Set<String> words = new HashSet<>(); for (String word : text.split(" ")) { words.add(word); } return words.iterator(); } }</pre>class Text { private final File file; Text(File src) { this.file = src; } @Override public String toString() { return new String( Files.readAllBytes(Paths.get(this.file)), "UTF-8" ); } } class Words implements Iterable<String> { private final String text; Words(String txt) { this.text = txt; } @Override public Iterator<String> iterator() { Set<String> words = new HashSet<>(); for (String word : this.text.split(" ")) { words.add(word); } return words.iterator(); } }</pre>Words class is a pretty trivial task:</p>import org.junit.Test; import static org.hamcrest.MatcherAssert.*; import static org.hamcrest.Matchers.*; public class WordsTest { @Test public void parsesSimpleText() { assertThat( new Words("How are you?"), hasItems("How", "are", "you") ); } }</pre>Words doesn’t do anything with files. It just parses the incoming string and finds the unique words in it. Now it’s easy to fix, since the test is small and we can easily create more tests; for example:</p>import org.junit.Test; import static org.hamcrest.MatcherAssert.*; import static org.hamcrest.Matchers.*; public class WordsTest { @Test public void parsesSimpleText() { assertThat( new Words("How are you?"), hasItems("How", "are", "you") ); } @Test public void parsesMultipleLines() { assertThat( new Words("first line\nsecond line\n"), hasItems("first", "second", "line") ); } }</pre>readWords() (a verb). To the contrary, the second example is about what will be achieved. It’s either the Text of the file or Words of the text (both are nouns).</p><p>I believe there is no place for debugging in clean object-oriented programming. Only unit testing!</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>12 Best</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>All 292</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Webinars</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Talks</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Books</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Papers</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Pets</li> <li /2016/02/03/design-patterns-and-anti-patterns.html class=”highlighted”>Trainings</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Award</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Testimonials</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Shift-M</li> <li /2016/02/03/design-patterns-and-anti-patterns.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/02/03/design-patterns-and-anti-patterns.html</p><h1 itemprop="name headline mainEntityOfPage">Design Patterns and Anti-Patterns, Love and Hate</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Palo Alto, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Design Patterns are … Come on, you know what they are. They are something we love and hate. We love them because they let us write code without thinking. We hate them when we see the code of someone who is used to writing code without thinking. Am I wrong? Now, let me try to go through all of them and show you how much I love or hate each one. Follow me, in alphabetic order.</p>
<figcaption id="27f582ec">The Shining (1980) by Stanley Kubrick</figcaption><div class="play"></div></div><div>Why Getters-and-Setters Is An Anti-Pattern? (webinar #4); 1 July 2015.</div></aside><p>Abstract Factory. It’s OK.</p><p>Adapter. Good one!</p><p>Bridge. Good one!</p><p>Builder. Terrible concept, since it encourages us to create and use big, complex objects. If you need a builder, there is already something wrong in your code. Refactor it so any object is easy to create through its constructors.</p><p>Chain of Responsibility. Seems fine.</p><p>Command. It’s OK.</p><p>Composite. Good one; check out this too.</p><p>Data Transfer Object. It’s just a shame.</p><p>Decorator. My favorite one. I highly recommend you use it.</p><p>Facade. Bad idea. In OOP, we need objects and only objects, not facades for them. This design pattern is very procedural in its spirit, since a facade is nothing more than a collection of procedures.</p><p>Factory Method. This one seems OK.</p><p>Flyweight. It’s a workaround, as I see it, so it’s not a good design pattern. I would recommend you not use it unless there is a really critical performance issue. But calling it a design pattern … no way. A fix for a performance problem in Java? Yes.</p><p>Front Controller. Terrible idea, as well as the entire MVC. It’s very procedural, that’s why.</p><p>Interpreter. It’s OK, but I don’t like the name. “Expression” would be a much better alternative.</p><p>Iterator. Bad idea, since it is mutable. It would be much better to have immutable “cursors.”</p><p>Lazy Initialization. It’s OK.</p><p>Marker. It’s a terrible idea, along with reflection and type casting.</p><p>MVC. Bad idea, since it’s very procedural. Controllers are the key broken element in this concept. We need real objects, not procedural controllers.</p><p>Mediator. I don’t like it. Even though it sounds like a technique for decreasing complexity and coupling, it is not really object-oriented. Who is this mediator? Just a “channel” between objects? Why shouldn’t objects communicate directly? Because they are too complex? Make them smaller and simpler, rather than inventing these mediators.</p><p>Memento. This idea implies that objects are mutable, which I’m against in general.</p><p>Module. If Wikipedia is right about this pattern, it’s something even more terrible than the Singleton.</p><p>Multiton. Really bad idea. Same as Singleton.</p><p>Null Object. Good one. By the way, see Why NULL Is Bad</p><p>Object Pool. Good one.</p><p>Observer. The idea is good, but the name is bad, since it ends with -ER. A much better one would be “Source” and “Target.” The Source generates events and the Target listens to them.</p><p>ORM. It’s terrible and “offensive”; check this out.</p><p>Prototype. Good idea, but what does it have to do with OOP?</p><p>Proxy. Good one.</p><p>RAII. This is a really good one, and I highly recommend you use it.</p><p>Servant. A very bad idea, because it’s highly procedural.</p><p>Singleton. It’s the king of all anti-patterns. Stay away from it at all costs.</p><p>Specification. It’s OK.</p><p>State. Although it’s not implied, I feel that in most cases the use of this pattern results in mutability, a code characteristic that I’m generally against.</p><p>Strategy. A good one.</p><p>Template Method. is wrong, since implementation inheritance is procedural.</p><p>Visitor. A rather procedural concept that treats objects as data structures, which we can manipulate.</p><hr /><p>I have nothing against concurrency patterns either; they are all good, since they have almost nothing to do with object-oriented programming.</p><p>If you know some other design (anti-)patterns, let me know in the comments below. I’ll add them here.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Design Patterns are … Come on, you know what they are. They are something we love and hate. We love them because they let us write code without thinking. We hate them when we see the code of someone who is used to writing code without thinking. Am I wrong? Now, let me try to go through all of them and show you how much I love or hate each one. Follow me, in alphabetic order.</p><figcaption id="27f582ec">The Shining (1980) by Stanley Kubrick</figcaption><div class="play"></div></div><div>Why Getters-and-Setters Is An Anti-Pattern? (webinar #4); 1 July 2015.</div></aside><p>Abstract Factory. It’s OK.</p><p>Adapter. Good one!</p><p>Bridge. Good one!</p><p>Builder. Terrible concept, since it encourages us to create and use big, complex objects. If you need a builder, there is already something wrong in your code. Refactor it so any object is easy to create through its constructors.</p><p>Chain of Responsibility. Seems fine.</p><p>Command. It’s OK.</p><p>Composite. Good one; check out this too.</p><p>Data Transfer Object. It’s just a shame.</p><p>Decorator. My favorite one. I highly recommend you use it.</p><p>Facade. Bad idea. In OOP, we need objects and only objects, not facades for them. This design pattern is very procedural in its spirit, since a facade is nothing more than a collection of procedures.</p><p>Factory Method. This one seems OK.</p><p>Flyweight. It’s a workaround, as I see it, so it’s not a good design pattern. I would recommend you not use it unless there is a really critical performance issue. But calling it a design pattern … no way. A fix for a performance problem in Java? Yes.</p><p>Front Controller. Terrible idea, as well as the entire MVC. It’s very procedural, that’s why.</p><p>Interpreter. It’s OK, but I don’t like the name. “Expression” would be a much better alternative.</p><p>Iterator. Bad idea, since it is mutable. It would be much better to have immutable “cursors.”</p><p>Lazy Initialization. It’s OK.</p><p>Marker. It’s a terrible idea, along with reflection and type casting.</p><p>MVC. Bad idea, since it’s very procedural. Controllers are the key broken element in this concept. We need real objects, not procedural controllers.</p><p>Mediator. I don’t like it. Even though it sounds like a technique for decreasing complexity and coupling, it is not really object-oriented. Who is this mediator? Just a “channel” between objects? Why shouldn’t objects communicate directly? Because they are too complex? Make them smaller and simpler, rather than inventing these mediators.</p><p>Memento. This idea implies that objects are mutable, which I’m against in general.</p><p>Module. If Wikipedia is right about this pattern, it’s something even more terrible than the Singleton.</p><p>Multiton. Really bad idea. Same as Singleton.</p><p>Null Object. Good one. By the way, see Why NULL Is Bad</p><p>Object Pool. Good one.</p><p>Observer. The idea is good, but the name is bad, since it ends with -ER. A much better one would be “Source” and “Target.” The Source generates events and the Target listens to them.</p><p>ORM. It’s terrible and “offensive”; check this out.</p><p>Prototype. Good idea, but what does it have to do with OOP?</p><p>Proxy. Good one.</p><p>RAII. This is a really good one, and I highly recommend you use it.</p><p>Servant. A very bad idea, because it’s highly procedural.</p><p>Singleton. It’s the king of all anti-patterns. Stay away from it at all costs.</p><p>Specification. It’s OK.</p><p>State. Although it’s not implied, I feel that in most cases the use of this pattern results in mutability, a code characteristic that I’m generally against.</p><p>Strategy. A good one.</p><p>Template Method. is wrong, since implementation inheritance is procedural.</p><p>Visitor. A rather procedural concept that treats objects as data structures, which we can manipulate.</p><hr /><p>I have nothing against concurrency patterns either; they are all good, since they have almost nothing to do with object-oriented programming.</p><p>If you know some other design (anti-)patterns, let me know in the comments below. I’ll add them here.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/01/26/defensive-programming.html>12 Best</li> <li /2016/01/26/defensive-programming.html>All 292</li> <li /2016/01/26/defensive-programming.html>Webinars</li> <li /2016/01/26/defensive-programming.html>Talks</li> <li /2016/01/26/defensive-programming.html>Books</li> <li /2016/01/26/defensive-programming.html>Papers</li> <li /2016/01/26/defensive-programming.html>Pets</li> <li /2016/01/26/defensive-programming.html class=”highlighted”>Trainings</li> <li /2016/01/26/defensive-programming.html>Award</li> <li /2016/01/26/defensive-programming.html>Testimonials</li> <li /2016/01/26/defensive-programming.html>Shift-M</li> <li /2016/01/26/defensive-programming.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/01/26/defensive-programming.html</p><h1 itemprop="name headline mainEntityOfPage">Defensive Programming via Validating Decorators</h1><aside class='book'>Read more about this subject in Section 5.2of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Palo Alto, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Do you check the input parameters of your methods for validity? I don’t. I used to, but not anymore. I just let my methods crash with a null pointer and other exceptions when parameters are not valid. This may sound illogical, but only in the beginning. I’m suggesting you use validating decorators instead.</p>
<figcaption id="7c52eb30">Shi mian mai fu (2004) by Yimou Zhang</figcaption>class Report { void export(File file) { if (file == null) { throw new IllegalArgumentException( "File is NULL; can't export." ); } if (file.exists()) { throw new IllegalArgumentException( "File already exists." ); } // Export the report to the file } }</pre>NULL is provided by the client. Moreover, if the file already exists, our Report will silently overwrite it. Pretty dangerous, right?</p><p>Yes, we must protect ourselves, and we must be defensive.</p><p>But not this way, not by bloating the class with validations that have nothing to do with its core functionality. Instead, we should use decorators to do the validation. Here is how. First, there must be an interface Report:</p>interface Report { void export(File file); }</pre>class DefaultReport implements Report { @Override void export(File file) { // Export the report to the file } }</pre>class NoWriteOverReport implements Report { private final Report origin; NoWriteOverReport(Report rep) { this.origin = rep; } @Override void export(File file) { if (file.exists()) { throw new IllegalArgumentException( "File already exists." ); } this.origin.export(file); } }</pre>Report report = new NoNullReport( new NoWriteOverReport( new DefaultReport() ) ); report.export(file);</pre>DefaultReport class will always remain small, no matter how many validations we may invent in the future. The more things we need to validate, the more validating decorators we will create. All of them will be small and cohesive. And we’ll be able to put them together in different variations.</p><p>Besides that, this approach makes our code much more reusable, as classes perform very few operations and don’t defend themselves by default. While being defensive is an important feature, we’ll use validating decorators. But this will not always be the case. Sometimes validation is just too expensive in terms of time and memory, and we may want to work directly with objects that don’t defend themselves.</p><p>I also decided not to use the Java Validation API anymore for the same reason. Its annotations make classes much more verbose and less cohesive. I’m using validating decorators instead.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Do you check the input parameters of your methods for validity? I don’t. I used to, but not anymore. I just let my methods crash with a null pointer and other exceptions when parameters are not valid. This may sound illogical, but only in the beginning. I’m suggesting you use validating decorators instead.</p><figcaption id="7c52eb30">Shi mian mai fu (2004) by Yimou Zhang</figcaption>class Report { void export(File file) { if (file == null) { throw new IllegalArgumentException( "File is NULL; can't export." ); } if (file.exists()) { throw new IllegalArgumentException( "File already exists." ); } // Export the report to the file } }</pre>NULL is provided by the client. Moreover, if the file already exists, our Report will silently overwrite it. Pretty dangerous, right?</p><p>Yes, we must protect ourselves, and we must be defensive.</p><p>But not this way, not by bloating the class with validations that have nothing to do with its core functionality. Instead, we should use decorators to do the validation. Here is how. First, there must be an interface Report:</p>interface Report { void export(File file); }</pre>class DefaultReport implements Report { @Override void export(File file) { // Export the report to the file } }</pre>class NoWriteOverReport implements Report { private final Report origin; NoWriteOverReport(Report rep) { this.origin = rep; } @Override void export(File file) { if (file.exists()) { throw new IllegalArgumentException( "File already exists." ); } this.origin.export(file); } }</pre>Report report = new NoNullReport( new NoWriteOverReport( new DefaultReport() ) ); report.export(file);</pre>DefaultReport class will always remain small, no matter how many validations we may invent in the future. The more things we need to validate, the more validating decorators we will create. All of them will be small and cohesive. And we’ll be able to put them together in different variations.</p><p>Besides that, this approach makes our code much more reusable, as classes perform very few operations and don’t defend themselves by default. While being defensive is an important feature, we’ll use validating decorators. But this will not always be the case. Sometimes validation is just too expensive in terms of time and memory, and we may want to work directly with objects that don’t defend themselves.</p><p>I also decided not to use the Java Validation API anymore for the same reason. Its annotations make classes much more verbose and less cohesive. I’m using validating decorators instead.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>12 Best</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>All 292</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Webinars</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Talks</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Books</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Papers</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Pets</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html class=”highlighted”>Trainings</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Award</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Testimonials</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Shift-M</li> <li /2016/01/12/good-programmers-dont-work-for-equity.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2016/01/12/good-programmers-dont-work-for-equity.html</p><h1 itemprop="name headline mainEntityOfPage">Good Programmers Don’t Work for Equity</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Los Angeles, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>“You’re a good programmer. I’m a great entrepreneur. This is a breakthrough idea. Help me build it. I don’t have cash, but I will give you equity. Deal?” I hear this at least once a month, and I always say no. Not because I don’t like your idea. Indeed, it is really interesting. And not because I’m too busy. I would definitely find time for a good idea. It’s not that. I say no because I don’t think you’re a good entrepreneur.</p>
<figcaption id="74a39f1f">Combien tu m'aimes? (2005) by Bertrand Blier</figcaption><figcaption id="74a39f1f">Combien tu m'aimes? (2005) by Bertrand Blier</figcaption> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>12 Best</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>All 292</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Webinars</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Talks</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Books</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Papers</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Pets</li> <li /2015/12/08/temporal-coupling-between-method-calls.html class=”highlighted”>Trainings</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Award</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Testimonials</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Shift-M</li> <li /2015/12/08/temporal-coupling-between-method-calls.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/12/08/temporal-coupling-between-method-calls.html</p><h1 itemprop="name headline mainEntityOfPage">Temporal Coupling Between Method Calls</h1><aside class='book'>Read more about this subject in Section 5.6of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Kiev, Ukraine</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Temporal coupling happens between sequential method calls when they must stay in a particular order. This is inevitable in imperative programming, but we can reduce the negative effect of it just by turning those static procedures into functions. Take a look at this example.</p>
<figcaption id="17ff3e16">Blueberry (2004) by Jan Kounen</figcaption>class Foo { public List<String> names() { List<String> list = new LinkedList(); Foo.append(list, "Jeff"); Foo.append(list, "Walter"); return list; } private static void append( List<String> list, String item) { list.add(item.toLowerCase()); } }</pre>names() is doing—creating a list of names. In order to avoid duplication, there is a supplementary procedure, append(), which converts an item to lowercase and adds it to the list.</p><p>This is poor design.</p><p>It is a procedural design, and there is temporal coupling between lines in method names().</p><p>Let me first show you a better (though not the best!) design, then I will try to explain its benefits:</p>class Foo { public List<String> names() { return Foo.with( Foo.with( new LinkedList(), "Jeff" ), "Walter" ); } private static List<String> with( List<String> list, String item) { list.add(item.toLowerCase()); return list; } }</pre>with() would create a new instance of List, populate it through addAll(list), then add(item) to it, and finally return. That would be perfectly immutable, but slow.</p><p>So, what is wrong with this:</p>List<String> list = new LinkedList(); Foo.append(list, "Jeff"); Foo.append(list, "Walter"); return list;</pre>append() is doing. In a few months, we’ll get back to this code, and it will look like this:</p>List<String> list = new LinkedList(); // 10 more lines here Foo.append(list, "Jeff"); Foo.append(list, "Walter"); // 10 more lines here return list;</pre>append() is actually adding "Jeff" to list? What will happen if I remove that line? Will it affect the result being returned in the last line? I don’t know. I need to check the body of method append() to make sure.</p><p>Also, how about returning list first and calling append() afterwards? This is what possible “refactoring” may do to our code:</p>List<String> list = new LinkedList(); if (/* something */) { return list; } // 10 more lines here Foo.append(list, "Walter"); Foo.append(list, "Jeff"); // 10 more lines here return list;</pre>list too early, when it is not ready. But did anyone tell me that these two calls to append() must happen before return list? Second, we changed the order of append() calls. Again, did anyone tell me that it’s important to call them in that particular order?</p><p>Nobody. Nowhere. This is called temporal coupling.</p><p>Our lines are coupled together. They must stay in this particular order, but the knowledge about that order is hidden. It’s easy to destroy the order, and our compiler won’t be able to catch us.</p><p>To the contrary, this design doesn’t have any “order”:</p>return Foo.with( Foo.with( new LinkedList(), "Jeff" ), "Walter" );</pre>with() method. It is a single line instead of four.</p><p>As discussed before, an ideal method in OOP must have just a single statement, and this statement is return.</p><p>The same is true about validation. For example, this code is bad:</p>list.add("Jeff"); Foo.checkIfListStillHasSpace(list); list.add("Walter");</pre>list.add("Jeff"); Foo.withEnoughSpace(list).add("Walter");</pre><figcaption id="17ff3e16">Blueberry (2004) by Jan Kounen</figcaption>class Foo { public List<String> names() { List<String> list = new LinkedList(); Foo.append(list, "Jeff"); Foo.append(list, "Walter"); return list; } private static void append( List<String> list, String item) { list.add(item.toLowerCase()); } }</pre>names() is doing—creating a list of names. In order to avoid duplication, there is a supplementary procedure, append(), which converts an item to lowercase and adds it to the list.</p><p>This is poor design.</p><p>It is a procedural design, and there is temporal coupling between lines in method names().</p><p>Let me first show you a better (though not the best!) design, then I will try to explain its benefits:</p>class Foo { public List<String> names() { return Foo.with( Foo.with( new LinkedList(), "Jeff" ), "Walter" ); } private static List<String> with( List<String> list, String item) { list.add(item.toLowerCase()); return list; } }</pre>with() would create a new instance of List, populate it through addAll(list), then add(item) to it, and finally return. That would be perfectly immutable, but slow.</p><p>So, what is wrong with this:</p>List<String> list = new LinkedList(); Foo.append(list, "Jeff"); Foo.append(list, "Walter"); return list;</pre>append() is doing. In a few months, we’ll get back to this code, and it will look like this:</p>List<String> list = new LinkedList(); // 10 more lines here Foo.append(list, "Jeff"); Foo.append(list, "Walter"); // 10 more lines here return list;</pre>append() is actually adding "Jeff" to list? What will happen if I remove that line? Will it affect the result being returned in the last line? I don’t know. I need to check the body of method append() to make sure.</p><p>Also, how about returning list first and calling append() afterwards? This is what possible “refactoring” may do to our code:</p>List<String> list = new LinkedList(); if (/* something */) { return list; } // 10 more lines here Foo.append(list, "Walter"); Foo.append(list, "Jeff"); // 10 more lines here return list;</pre>list too early, when it is not ready. But did anyone tell me that these two calls to append() must happen before return list? Second, we changed the order of append() calls. Again, did anyone tell me that it’s important to call them in that particular order?</p><p>Nobody. Nowhere. This is called temporal coupling.</p><p>Our lines are coupled together. They must stay in this particular order, but the knowledge about that order is hidden. It’s easy to destroy the order, and our compiler won’t be able to catch us.</p><p>To the contrary, this design doesn’t have any “order”:</p>return Foo.with( Foo.with( new LinkedList(), "Jeff" ), "Walter" );</pre>with() method. It is a single line instead of four.</p><p>As discussed before, an ideal method in OOP must have just a single statement, and this statement is return.</p><p>The same is true about validation. For example, this code is bad:</p>list.add("Jeff"); Foo.checkIfListStillHasSpace(list); list.add("Walter");</pre>list.add("Jeff"); Foo.withEnoughSpace(list).add("Walter");</pre> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/12/01/rethrow-exceptions.html>12 Best</li> <li /2015/12/01/rethrow-exceptions.html>All 292</li> <li /2015/12/01/rethrow-exceptions.html>Webinars</li> <li /2015/12/01/rethrow-exceptions.html>Talks</li> <li /2015/12/01/rethrow-exceptions.html>Books</li> <li /2015/12/01/rethrow-exceptions.html>Papers</li> <li /2015/12/01/rethrow-exceptions.html>Pets</li> <li /2015/12/01/rethrow-exceptions.html class=”highlighted”>Trainings</li> <li /2015/12/01/rethrow-exceptions.html>Award</li> <li /2015/12/01/rethrow-exceptions.html>Testimonials</li> <li /2015/12/01/rethrow-exceptions.html>Shift-M</li> <li /2015/12/01/rethrow-exceptions.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/12/01/rethrow-exceptions.html</p><h1 itemprop="name headline mainEntityOfPage">Throwing an Exception Without Proper Context Is a Bad Habit</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">San Jose, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>I keep repeating the same mistake again and again. So it’s time to stop and make a rule to prevent this from happening anymore. The mistake is not fatal, but it’s very annoying. When I look at production logs, I often see something like "File doesn't exist", and I ask myself: What file? Where is it supposed to exist? What did the server try to do with it? What was going on a second before it crashed? There is no answer in the log, and it’s totally my fault. I either 1) don’t re-throw or 2) re-throw without providing context. Both are wrong.</p>
<figcaption id="ddf945c0">Four Rooms (1995) by Allison Anders et al.</figcaption>if (!file.exists()) { throw new IllegalArgumentException( "File doesn't exist" ); }</pre>try { Files.delete(file); } catch (IOException ex) { throw new IllegalArgumentException(ex); }</pre>if (!file.exists()) { throw new IllegalArgumentException( String.format( "User profile file %s doesn't exist", file.getAbsolutePath() ) ); }</pre>try { Files.delete(file); } catch (IOException ex) { throw new IllegalArgumentException( String.format( "Can't delete user profile data file %s", file.getAbsolutePath() ), ex ); }</pre>throw new IllegalArgumentException( "File doesn't exist" );</pre>"File doesn't exist", and I ask myself: What file? Where is it supposed to exist? What did the server try to do with it? What was going on a second before it crashed? There is no answer in the log, and it’s totally my fault. I either 1) don’t re-throw or 2) re-throw without providing context. Both are wrong.</p><figcaption id="ddf945c0">Four Rooms (1995) by Allison Anders et al.</figcaption>if (!file.exists()) { throw new IllegalArgumentException( "File doesn't exist" ); }</pre>try { Files.delete(file); } catch (IOException ex) { throw new IllegalArgumentException(ex); }</pre>if (!file.exists()) { throw new IllegalArgumentException( String.format( "User profile file %s doesn't exist", file.getAbsolutePath() ) ); }</pre>try { Files.delete(file); } catch (IOException ex) { throw new IllegalArgumentException( String.format( "Can't delete user profile data file %s", file.getAbsolutePath() ), ex ); }</pre>throw new IllegalArgumentException( "File doesn't exist" );</pre> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/10/01/vertical-horizontal-decorating.html>12 Best</li> <li /2015/10/01/vertical-horizontal-decorating.html>All 292</li> <li /2015/10/01/vertical-horizontal-decorating.html>Webinars</li> <li /2015/10/01/vertical-horizontal-decorating.html>Talks</li> <li /2015/10/01/vertical-horizontal-decorating.html>Books</li> <li /2015/10/01/vertical-horizontal-decorating.html>Papers</li> <li /2015/10/01/vertical-horizontal-decorating.html>Pets</li> <li /2015/10/01/vertical-horizontal-decorating.html class=”highlighted”>Trainings</li> <li /2015/10/01/vertical-horizontal-decorating.html>Award</li> <li /2015/10/01/vertical-horizontal-decorating.html>Testimonials</li> <li /2015/10/01/vertical-horizontal-decorating.html>Shift-M</li> <li /2015/10/01/vertical-horizontal-decorating.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/10/01/vertical-horizontal-decorating.html</p><h1 itemprop="name headline mainEntityOfPage">Vertical and Horizontal Decorating</h1><aside class='book'>Read more about this subject in Section 3.2.6of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Moscow, Russia</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>A decorator pattern is one of the best ways to add features to an object without changing its interface. I use composable decorators quite often and always question myself as to how to design them right when the list of features must be configurable. I’m not sure I have the right answer, but here is some food for thought.</p>
<figcaption id="3406debc">The Apartment (1960) by Billy Wilder</figcaption>interface Numbers { Iterable<Integer> iterate(); }</pre>Numbers numbers = new Sorted( new Unique( new Odds( new Positive( new ArrayNumbers( new Integer[] { -1, 78, 4, -34, 98, 4, } ) ) ) ) );</pre>Numbers numbers = new Modified( new ArrayNumbers( new Integer[] { -1, 78, 4, -34, 98, 4, } ), new Diff[] { new Positive(), new Odds(), new Unique(), new Sorted(), } );</pre>ArrayNumbers “vertically,” adding functionality through the composable decorators Positive, Odds, Unique, and Sorted.</p><p>The second approach introduces the new interface Diff, which implements the core functionality of iterating numbers through instances of Positive, Odds, Unique, and Sorted:</p>interface Diff { Iterable<Integer> apply(Iterable<Integer> origin); }</pre>numbers, both approaches are the same. The difference is only in the design. Which one is better and when? It seems that vertical decorating is easier to implement and is more suitable for smaller objects that expose just a few methods.</p><p>As for my experience, I always tend to start with vertical decorating since it’s easier to implement but eventually migrate to a horizontal one when the number of decorators starts to grow.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>A decorator pattern is one of the best ways to add features to an object without changing its interface. I use composable decorators quite often and always question myself as to how to design them right when the list of features must be configurable. I’m not sure I have the right answer, but here is some food for thought.</p><figcaption id="3406debc">The Apartment (1960) by Billy Wilder</figcaption>interface Numbers { Iterable<Integer> iterate(); }</pre>Numbers numbers = new Sorted( new Unique( new Odds( new Positive( new ArrayNumbers( new Integer[] { -1, 78, 4, -34, 98, 4, } ) ) ) ) );</pre>Numbers numbers = new Modified( new ArrayNumbers( new Integer[] { -1, 78, 4, -34, 98, 4, } ), new Diff[] { new Positive(), new Odds(), new Unique(), new Sorted(), } );</pre>ArrayNumbers “vertically,” adding functionality through the composable decorators Positive, Odds, Unique, and Sorted.</p><p>The second approach introduces the new interface Diff, which implements the core functionality of iterating numbers through instances of Positive, Odds, Unique, and Sorted:</p>interface Diff { Iterable<Integer> apply(Iterable<Integer> origin); }</pre>numbers, both approaches are the same. The difference is only in the design. Which one is better and when? It seems that vertical decorating is easier to implement and is more suitable for smaller objects that expose just a few methods.</p><p>As for my experience, I always tend to start with vertical decorating since it’s easier to implement but eventually migrate to a horizontal one when the number of decorators starts to grow.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/09/10/testing-exit-criteria.html>12 Best</li> <li /2015/09/10/testing-exit-criteria.html>All 292</li> <li /2015/09/10/testing-exit-criteria.html>Webinars</li> <li /2015/09/10/testing-exit-criteria.html>Talks</li> <li /2015/09/10/testing-exit-criteria.html>Books</li> <li /2015/09/10/testing-exit-criteria.html>Papers</li> <li /2015/09/10/testing-exit-criteria.html>Pets</li> <li /2015/09/10/testing-exit-criteria.html class=”highlighted”>Trainings</li> <li /2015/09/10/testing-exit-criteria.html>Award</li> <li /2015/09/10/testing-exit-criteria.html>Testimonials</li> <li /2015/09/10/testing-exit-criteria.html>Shift-M</li> <li /2015/09/10/testing-exit-criteria.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/09/10/testing-exit-criteria.html</p><h1 itemprop="name headline mainEntityOfPage">When Do You Stop Testing?</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Moscow, Russia</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="subline"> <li>Republished in:</li> <li>BLOG@CACM</li></ul><p class="unprintable"><p>There is a software to be tested. There is a team of testers. There is some money in the budget. There is some time in the schedule. We start right now. Testers are trying to break the product, finding bugs, reporting bugs, communicating with programmers when necessary, doing their best to find what’s wrong. Eventually they stop and say “we’re done.” How do they know when to stop? When there is enough testing? It’s obvious—when there are no more bugs left and the product can be shipped! If you think like this, I have bad news for you. You’re fundamentally wrong.</p>
<figcaption id="3e0b5dd3">La fille sur le pont (1999) by Patrice Leconte</figcaption>
<div class="play"></div></div><div>How Do You Know When Your Product is Ready to be Shipped?; 18 November 2016.</div></aside><p>Second, any software has an unlimited amount of bugs. Dr. Myers says that “you cannot test a program to guarantee that it is error free” (page 10) and that “it is impractical, often impossible, to find all the errors in a program” (page 8). This is also what most testers don’t understand. They believe that there is a limited number of bugs, which they have to find and call it a day. There literally no limit! The amount of bugs is unlimited, in any software product. No matter how small or big, complex or simple, new or old is the product.</p><aside class="quote">They can’t find all bugs, no matter how much time we give them</aside><p>Having these axioms in mind, let’s try to decide when testers have to stop. According to Dr. Myers, “one of the most difficult questions to answer when testing a program is determining when to stop, since there is no way of knowing if the error just detected is the last remaining error” (page 135).</p><p>They can’t find all bugs, no matter how much time we give them. And they are motivated to find more and more of them. But at some point of time we must make a decision and release the product. Looks like we will release it with bugs inside? Yes, indeed! We will release a product full of bugs. The only question is how many of them were found already and how critical they were.</p><p>Let’s put it all together. There are too many bugs to be able to find all of them in a reasonable amount of time. However, we have to release a new version, sooner or later. At the same time, testers will always tell us that there are more bugs there and they can find more, just need more time. What to do?</p><p>Dr. Myers says that “since the goal of testing is to find errors, why not make the completion criterion the detection of some predefined number of errors?” (page 136). Indeed, we should predict how many bugs are just enough to find, in order to have a desirable level of confidence that the product is ready to be shipped. Then, ship it, consciously understanding that it still has an unlimited amount of not yet discovered bugs.</p>
<figcaption id="3e0b5dd3">La fille sur le pont (1999) by Patrice Leconte</figcaption><div class="play"></div></div><div>How Do You Know When Your Product is Ready to be Shipped?; 18 November 2016.</div></aside><p>Second, any software has an unlimited amount of bugs. Dr. Myers says that “you cannot test a program to guarantee that it is error free” (page 10) and that “it is impractical, often impossible, to find all the errors in a program” (page 8). This is also what most testers don’t understand. They believe that there is a limited number of bugs, which they have to find and call it a day. There literally no limit! The amount of bugs is unlimited, in any software product. No matter how small or big, complex or simple, new or old is the product.</p><aside class="quote">They can’t find all bugs, no matter how much time we give them</aside><p>Having these axioms in mind, let’s try to decide when testers have to stop. According to Dr. Myers, “one of the most difficult questions to answer when testing a program is determining when to stop, since there is no way of knowing if the error just detected is the last remaining error” (page 135).</p><p>They can’t find all bugs, no matter how much time we give them. And they are motivated to find more and more of them. But at some point of time we must make a decision and release the product. Looks like we will release it with bugs inside? Yes, indeed! We will release a product full of bugs. The only question is how many of them were found already and how critical they were.</p><p>Let’s put it all together. There are too many bugs to be able to find all of them in a reasonable amount of time. However, we have to release a new version, sooner or later. At the same time, testers will always tell us that there are more bugs there and they can find more, just need more time. What to do?</p><p>Dr. Myers says that “since the goal of testing is to find errors, why not make the completion criterion the detection of some predefined number of errors?” (page 136). Indeed, we should predict how many bugs are just enough to find, in order to have a desirable level of confidence that the product is ready to be shipped. Then, ship it, consciously understanding that it still has an unlimited amount of not yet discovered bugs.</p> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/08/25/fail-fast.html>12 Best</li> <li /2015/08/25/fail-fast.html>All 292</li> <li /2015/08/25/fail-fast.html>Webinars</li> <li /2015/08/25/fail-fast.html>Talks</li> <li /2015/08/25/fail-fast.html>Books</li> <li /2015/08/25/fail-fast.html>Papers</li> <li /2015/08/25/fail-fast.html>Pets</li> <li /2015/08/25/fail-fast.html class=”highlighted”>Trainings</li> <li /2015/08/25/fail-fast.html>Award</li> <li /2015/08/25/fail-fast.html>Testimonials</li> <li /2015/08/25/fail-fast.html>Shift-M</li> <li /2015/08/25/fail-fast.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/08/25/fail-fast.html</p><h1 itemprop="name headline mainEntityOfPage">Need Robust Software? Make It Fragile</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Dnipro, Ukraine</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="subline"> <li>Discussed at:</li> <li>reddit</li></ul><p class="unprintable"><p>In any software project, the goal is to create something stable. We don’t want it to break in front of a user. We also don’t want our website to show an “internal application error” instead of a web page. We want our software to work, not fail. That’s a perfectly valid and logical desire, but in order to achieve that, we have to make our software as fragile as possible. This may sound counter-intuitive, but that’s the way it is. The more fragile your app is in development, the more robust it is in production.</p>
<figcaption id="28b040eb">Black Cat, White Cat (1998) by Emir Kusturica</figcaption>public int size(File file) { if (!file.exists()) { return 0; } return file.length(); }</pre>
<div class="play"></div></div><div>Need Robust Software? Make It Fragile; 29 February 2016.</div></aside><p>This method is supposed to calculate and return a file size. It first checks whether the file exists. If it doesn’t exist, the method returns zero. Indeed, the file is absent, so there is no size. We could complain that the file is absent, but what for? Why make noise? Let’s keep it quiet and return zero. We don’t fail because we’re trying to keep the app running. This is called Fail Safe.</p><p>To the contrary, this is how Fail Fast looks:</p>public int size(File file) { if (!file.exists()) { throw new IllegalArgumentException( "There is no such file; I can't get its length." ); } return file.length(); }</pre>
<div class="play"></div></div><div>Need It Robust? Make It Fragile!; 21 May 2016.</div></aside><p>In this example, if the method returns zero, it’s not obvious whether the file exists and its size is actually zero or if its name is wrong and it is just not found. The Fail Safe approach conceals problems and makes code less maintainable, and that’s why it’s difficult to stabilize.</p><p>In the beginning, during production, we will have many crashes and errors. But all of them will be visible and easy to understand. We will fix them and cover them with unit tests. Each fix will make our software more stable and better covered by tests.</p><p>Software designed with the Fail Safe approach in mind will look more stable at the beginning, but it will degrade quickly and inevitably turn into an unmaintainable mess.</p><p>Software designed with the Fail Fast approach in mind will crash frequently at the beginning but will improve its stability with every fix and eventually become very stable and robust.</p><p>That’s why fragility is the key success factor for robustness.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>In any software project, the goal is to create something stable. We don’t want it to break in front of a user. We also don’t want our website to show an “internal application error” instead of a web page. We want our software to work, not fail. That’s a perfectly valid and logical desire, but in order to achieve that, we have to make our software as fragile as possible. This may sound counter-intuitive, but that’s the way it is. The more fragile your app is in development, the more robust it is in production.</p><figcaption id="28b040eb">Black Cat, White Cat (1998) by Emir Kusturica</figcaption>public int size(File file) { if (!file.exists()) { return 0; } return file.length(); }</pre><div class="play"></div></div><div>Need Robust Software? Make It Fragile; 29 February 2016.</div></aside><p>This method is supposed to calculate and return a file size. It first checks whether the file exists. If it doesn’t exist, the method returns zero. Indeed, the file is absent, so there is no size. We could complain that the file is absent, but what for? Why make noise? Let’s keep it quiet and return zero. We don’t fail because we’re trying to keep the app running. This is called Fail Safe.</p><p>To the contrary, this is how Fail Fast looks:</p>public int size(File file) { if (!file.exists()) { throw new IllegalArgumentException( "There is no such file; I can't get its length." ); } return file.length(); }</pre><div class="play"></div></div><div>Need It Robust? Make It Fragile!; 21 May 2016.</div></aside><p>In this example, if the method returns zero, it’s not obvious whether the file exists and its size is actually zero or if its name is wrong and it is just not found. The Fail Safe approach conceals problems and makes code less maintainable, and that’s why it’s difficult to stabilize.</p><p>In the beginning, during production, we will have many crashes and errors. But all of them will be visible and easy to understand. We will fix them and cover them with unit tests. Each fix will make our software more stable and better covered by tests.</p><p>Software designed with the Fail Safe approach in mind will look more stable at the beginning, but it will degrade quickly and inevitably turn into an unmaintainable mess.</p><p>Software designed with the Fail Fast approach in mind will crash frequently at the beginning but will improve its stability with every fix and eventually become very stable and robust.</p><p>That’s why fragility is the key success factor for robustness.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>12 Best</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>All 292</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Webinars</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Talks</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Books</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Papers</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Pets</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html class=”highlighted”>Trainings</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Award</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Testimonials</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Shift-M</li> <li /2015/07/28/checked-vs-unchecked-exceptions.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/07/28/checked-vs-unchecked-exceptions.html</p><h1 itemprop="name headline mainEntityOfPage">Checked vs. Unchecked Exceptions: The Debate Is Not Over</h1><aside class='book'>Read more about this subject in Section 4.2of my book
</aside><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Sunnyvale, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Do we need checked exceptions at all? The debate is over, isn’t it? Not for me. While most object-oriented languages don’t have them, and most programmers think checked exceptions are a Java mistake, I believe in the opposite—unchecked exceptions are the mistake. Moreover, I believe multiple exception types are a bad idea too.</p>
<figcaption id="443dfa82">True Romance (1993) by Tony Scott</figcaption>public void save(File file, byte[] data) throws Exception { // save data to the file }</pre>Exception and we have to do something about it:</p>try { save(file, data); } catch (Exception ex) { System.out.println("Sorry, we can't save right now."); }</pre>throws an exception, I understand that the method is not safe. It may fail sometimes, and it’s my responsibility to either 1) handle this failure or 2) declare myself as unsafe too.</p><p>I know each method is designed with a single responsibility principle in mind. This is a guarantee to me that if method save() fails, it means the entire saving operation can’t be completed. If I need to know what the cause of this failure was, I will un-chain the exception—traverse the stack of chained exceptions and stack traces encapsulated in ex.</p><p>I never use exceptions for flow control, which means I never recover situations where exceptions are thrown. When an exception occurs, I let it float up to the highest level of the application. Sometimes I rethrow it in order to add more semantic information to the chain. That’s why it doesn’t matter to me what the cause of the exception thrown by save() was. I just know the method failed. That’s enough for me. Always.</p><p>For the same reason, I don’t need to differentiate between different exception types. I just don’t need that type of hierarchy. Exception is enough for me. Again, that’s because I don’t use exceptions for flow control.</p><p>That’s how I understand exceptions.</p><p>According to this paradigm, I would say we must:</p><ul> <li>Always use checked exceptions.</li> <li>Never throw/use unchecked exceptions.</li> <li>Use only Exception, without any sub-types.</li> <li>Always declare one exception type in the throws block.</li> <li>Never catch without rethrowing; read more about that here.</li></ul><p>This paradigm diverges from many other articles I’ve found on this subject. Let’s compare and discuss.</p><h2 id="runtime-vs-api-exceptions">Runtime vs. API Exceptions</h2><p>Oracle says some exceptions should be part of API (checked ones) while some are runtime exceptions and should not be part of it (unchecked). They will be documented in JavaDoc but not in the method signature.</p><p>I don’t understand the logic here, and I’m sure Java designers don’t understand it either. How and why are some exceptions important while others are not? Why do some of them deserve a proper API position in the throws block of the method signature while others don’t? What is the criteria?</p><p>I have an answer here, though. By introducing checked and unchecked exceptions, Java developers tried to solve the problem of methods that are too complex and messy. When a method is too big and does too many things at the same time (violates the single responsibility principle), it’s definitely better to let us keep some exceptions “hidden” (a.k.a. unchecked). But it’s not a real solution. It is only a temporary patch that does all of us more harm than good—methods keep growing in size and complexity.</p><p>Unchecked exceptions are a mistake in Java design, not checked ones.</p><p>Hiding the fact that a method may fail at some point is a mistake. That’s exactly what unchecked exceptions do.</p><p>Instead, we should make this fact visible. When a method does too many things, there will be too many points of failure, and the author of the method will realize that something is wrong—a method should not throw exceptions in so many situations. This will lead to refactoring. The existence of unchecked exceptions leads to a mess. By the way, checked exceptions don’t exist at all in Ruby, C#, Python, PHP, etc. This means that creators of these languages understand OOP even less than Java authors.</p><h2 id="checked-exceptions-are-too-noisy">Checked Exceptions Are Too Noisy</h2><p>Another common argument against checked exceptions is that they make our code more verbose. We have to put try/catch everywhere instead of staying focused on the main logic. Bozhidar Bozhanov even suggests a technical solution for this verbosity problem.</p><p>Again, I don’t understand this logic. If I want to do something when method save() fails, I catch the exception and handle the situation somehow. If I don’t want to do that, I just say my method also throws and pay no attention to exception handling. What is the problem? Where is the verbosity coming from?</p><p>I have an answer here, too. It’s coming from the existence of unchecked exceptions. We simply can’t always ignore failure, because the interfaces we’re using don’t allow us to do this. That’s all. For example, class Runnable, which is widely used for multi-thread programming, has method run() that is not supposed to throw anything. That’s why we always have to catch everything inside the method and rethrow checked exceptions as unchecked.</p><p>If all methods in all Java interfaces would be declared either as “safe” (throws nothing) or “unsafe” (throws Exception), everything would become logical and clear. If you want to stay “safe,” take responsibility for failure handling. Otherwise, be “unsafe” and let your users worry about safety.</p><p>No noise, very clean code, and obvious logic.</p><h2 id="inappropriately-exposed-implementation-details">Inappropriately Exposed Implementation Details</h2><p>Some say the ability to put a checked exception into throws in the method signature instead of catching it here and rethrowing a new type encourages us to have too many irrelevant exception types in method signatures. For example, our method save() may declare that it may throw OutOfMemoryException, even though it seems to have nothing to do with memory allocation. But it does allocate some memory, right? So such a memory overflow may happen during a file saving operation.</p><p>Yet again, I don’t get the logic of this argument. If all exceptions are checked, and we don’t have multiple exception types, we just throw Exception everywhere, and that’s it. Why do we need to care about the exception type in the first place? If we don’t use exceptions to control flow, we won’t do this.</p><p>If we really want to make our application memory overflow-resistant, we will introduce some memory manager, which will have something like the bigEnough() method, which will tell us whether our heap is big enough for the next operation. Using exceptions in such situations is a totally inappropriate approach to exception management in OOP.</p><h2 id="recoverable-exceptions">Recoverable Exceptions</h2><p>Joshua Bloch, in Effective Java, says to “use checked exceptions for recoverable conditions and runtime exceptions for programming errors.” He means something like this:</p>try { save(file, data); } catch (Exception ex) { // We can't save the file, but it's OK // Let's move on and do something else }</pre>App#run() Data#update() Data#write() File#save() <-- Boom, there's a failure here, so we go up</pre>throw. In other words, we don’t do anything in the catch block. We only report the problem and wrap up execution. We never “recover!”</p><hr /><p>All arguments against checked exceptions demonstrate nothing but a serious misunderstanding of object-oriented programming by their authors. The mistake in Java and in many other languages is the existence of unchecked exceptions, not checked ones.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Do we need checked exceptions at all? The debate is over, isn’t it? Not for me. While most object-oriented languages don’t have them, and most programmers think checked exceptions are a Java mistake, I believe in the opposite—unchecked exceptions are the mistake. Moreover, I believe multiple exception types are a bad idea too.</p><figcaption id="443dfa82">True Romance (1993) by Tony Scott</figcaption>public void save(File file, byte[] data) throws Exception { // save data to the file }</pre>Exception and we have to do something about it:</p>try { save(file, data); } catch (Exception ex) { System.out.println("Sorry, we can't save right now."); }</pre>throws an exception, I understand that the method is not safe. It may fail sometimes, and it’s my responsibility to either 1) handle this failure or 2) declare myself as unsafe too.</p><p>I know each method is designed with a single responsibility principle in mind. This is a guarantee to me that if method save() fails, it means the entire saving operation can’t be completed. If I need to know what the cause of this failure was, I will un-chain the exception—traverse the stack of chained exceptions and stack traces encapsulated in ex.</p><p>I never use exceptions for flow control, which means I never recover situations where exceptions are thrown. When an exception occurs, I let it float up to the highest level of the application. Sometimes I rethrow it in order to add more semantic information to the chain. That’s why it doesn’t matter to me what the cause of the exception thrown by save() was. I just know the method failed. That’s enough for me. Always.</p><p>For the same reason, I don’t need to differentiate between different exception types. I just don’t need that type of hierarchy. Exception is enough for me. Again, that’s because I don’t use exceptions for flow control.</p><p>That’s how I understand exceptions.</p><p>According to this paradigm, I would say we must:</p><ul> <li>Always use checked exceptions.</li> <li>Never throw/use unchecked exceptions.</li> <li>Use only Exception, without any sub-types.</li> <li>Always declare one exception type in the throws block.</li> <li>Never catch without rethrowing; read more about that here.</li></ul><p>This paradigm diverges from many other articles I’ve found on this subject. Let’s compare and discuss.</p><h2 id="runtime-vs-api-exceptions">Runtime vs. API Exceptions</h2><p>Oracle says some exceptions should be part of API (checked ones) while some are runtime exceptions and should not be part of it (unchecked). They will be documented in JavaDoc but not in the method signature.</p><p>I don’t understand the logic here, and I’m sure Java designers don’t understand it either. How and why are some exceptions important while others are not? Why do some of them deserve a proper API position in the throws block of the method signature while others don’t? What is the criteria?</p><p>I have an answer here, though. By introducing checked and unchecked exceptions, Java developers tried to solve the problem of methods that are too complex and messy. When a method is too big and does too many things at the same time (violates the single responsibility principle), it’s definitely better to let us keep some exceptions “hidden” (a.k.a. unchecked). But it’s not a real solution. It is only a temporary patch that does all of us more harm than good—methods keep growing in size and complexity.</p><p>Unchecked exceptions are a mistake in Java design, not checked ones.</p><p>Hiding the fact that a method may fail at some point is a mistake. That’s exactly what unchecked exceptions do.</p><p>Instead, we should make this fact visible. When a method does too many things, there will be too many points of failure, and the author of the method will realize that something is wrong—a method should not throw exceptions in so many situations. This will lead to refactoring. The existence of unchecked exceptions leads to a mess. By the way, checked exceptions don’t exist at all in Ruby, C#, Python, PHP, etc. This means that creators of these languages understand OOP even less than Java authors.</p><h2 id="checked-exceptions-are-too-noisy">Checked Exceptions Are Too Noisy</h2><p>Another common argument against checked exceptions is that they make our code more verbose. We have to put try/catch everywhere instead of staying focused on the main logic. Bozhidar Bozhanov even suggests a technical solution for this verbosity problem.</p><p>Again, I don’t understand this logic. If I want to do something when method save() fails, I catch the exception and handle the situation somehow. If I don’t want to do that, I just say my method also throws and pay no attention to exception handling. What is the problem? Where is the verbosity coming from?</p><p>I have an answer here, too. It’s coming from the existence of unchecked exceptions. We simply can’t always ignore failure, because the interfaces we’re using don’t allow us to do this. That’s all. For example, class Runnable, which is widely used for multi-thread programming, has method run() that is not supposed to throw anything. That’s why we always have to catch everything inside the method and rethrow checked exceptions as unchecked.</p><p>If all methods in all Java interfaces would be declared either as “safe” (throws nothing) or “unsafe” (throws Exception), everything would become logical and clear. If you want to stay “safe,” take responsibility for failure handling. Otherwise, be “unsafe” and let your users worry about safety.</p><p>No noise, very clean code, and obvious logic.</p><h2 id="inappropriately-exposed-implementation-details">Inappropriately Exposed Implementation Details</h2><p>Some say the ability to put a checked exception into throws in the method signature instead of catching it here and rethrowing a new type encourages us to have too many irrelevant exception types in method signatures. For example, our method save() may declare that it may throw OutOfMemoryException, even though it seems to have nothing to do with memory allocation. But it does allocate some memory, right? So such a memory overflow may happen during a file saving operation.</p><p>Yet again, I don’t get the logic of this argument. If all exceptions are checked, and we don’t have multiple exception types, we just throw Exception everywhere, and that’s it. Why do we need to care about the exception type in the first place? If we don’t use exceptions to control flow, we won’t do this.</p><p>If we really want to make our application memory overflow-resistant, we will introduce some memory manager, which will have something like the bigEnough() method, which will tell us whether our heap is big enough for the next operation. Using exceptions in such situations is a totally inappropriate approach to exception management in OOP.</p><h2 id="recoverable-exceptions">Recoverable Exceptions</h2><p>Joshua Bloch, in Effective Java, says to “use checked exceptions for recoverable conditions and runtime exceptions for programming errors.” He means something like this:</p>try { save(file, data); } catch (Exception ex) { // We can't save the file, but it's OK // Let's move on and do something else }</pre>App#run() Data#update() Data#write() File#save() <-- Boom, there's a failure here, so we go up</pre>throw. In other words, we don’t do anything in the catch block. We only report the problem and wrap up execution. We never “recover!”</p><hr /><p>All arguments against checked exceptions demonstrate nothing but a serious misunderstanding of object-oriented programming by their authors. The mistake in Java and in many other languages is the existence of unchecked exceptions, not checked ones.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/07/16/fools-dont-write-unit-tests.html>12 Best</li> <li /2015/07/16/fools-dont-write-unit-tests.html>All 292</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Webinars</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Talks</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Books</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Papers</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Pets</li> <li /2015/07/16/fools-dont-write-unit-tests.html class=”highlighted”>Trainings</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Award</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Testimonials</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Shift-M</li> <li /2015/07/16/fools-dont-write-unit-tests.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/07/16/fools-dont-write-unit-tests.html</p><h1 itemprop="name headline mainEntityOfPage">Fools Don’t Write Unit Tests</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Palo Alto, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>“We don’t have time to write unit tests” or “We don’t have the budget for unit testing” are complaints I hear very often. Sometimes it may sound like, “We don’t use TDD, so that’s why there are no unit tests,” or even “TDD is too expensive for us now.” I’m sure you’ve heard this or even said it yourself. It doesn’t make any sense to me. I don’t get the logic. In my understanding, unit testing is not a product; it’s a tool. You use tests to develop a product faster and better. How can you say you don’t have time to use the tool that makes your work faster? Let me show you how.</p>
<figcaption id="2b57602a">Ex Machina (2015) by Alex Garland</figcaption>Cmd+R many times. That will work for a primitive piece of code and only for you, a single developer of it. But I hear this “I don’t have time” argument from programmers working on enterprise systems. How do you guys test your code?</p><aside class="quote">Not because you didn’t have time, you just didn’t know how</aside><p>I would compare unit tests with OOP classes. You can design the entire application in a single class with a few thousand methods. You will save time on creating other classes, structuring them, thinking about connections between them, etc. It will be a single 20,000-line .java file. And you’ll say that “you didn’t have time to create classes,” right? What would we say about such a product and the author of it? Right, we’d say he or she is just stupid. And it has nothing to do with time or budget. Such a programmer just doesn’t know how to use object-oriented programming tools, like encapsulation, inheritance, polymorphism, interfaces, method overloading, etc. It’s not about time or budget; it’s about skills and discipline.</p><p>The same is true for unit tests. If you create code without unit tests, it may work, just like that monster class with 20,000 lines, but the quality of your product will be very low. And not because you didn’t have time to write unit tests, but because you didn’t know how to do it.</p><p>So every time I hear, “I didn’t have time for unit testing,” I understand that you just didn’t know how and are trying to conceal that fact behind false excuses. It’s not professional, to say the least.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>“We don’t have time to write unit tests” or “We don’t have the budget for unit testing” are complaints I hear very often. Sometimes it may sound like, “We don’t use TDD, so that’s why there are no unit tests,” or even “TDD is too expensive for us now.” I’m sure you’ve heard this or even said it yourself. It doesn’t make any sense to me. I don’t get the logic. In my understanding, unit testing is not a product; it’s a tool. You use tests to develop a product faster and better. How can you say you don’t have time to use the tool that makes your work faster? Let me show you how.</p><figcaption id="2b57602a">Ex Machina (2015) by Alex Garland</figcaption>Cmd+R many times. That will work for a primitive piece of code and only for you, a single developer of it. But I hear this “I don’t have time” argument from programmers working on enterprise systems. How do you guys test your code?</p><aside class="quote">Not because you didn’t have time, you just didn’t know how</aside><p>I would compare unit tests with OOP classes. You can design the entire application in a single class with a few thousand methods. You will save time on creating other classes, structuring them, thinking about connections between them, etc. It will be a single 20,000-line .java file. And you’ll say that “you didn’t have time to create classes,” right? What would we say about such a product and the author of it? Right, we’d say he or she is just stupid. And it has nothing to do with time or budget. Such a programmer just doesn’t know how to use object-oriented programming tools, like encapsulation, inheritance, polymorphism, interfaces, method overloading, etc. It’s not about time or budget; it’s about skills and discipline.</p><p>The same is true for unit tests. If you create code without unit tests, it may work, just like that monster class with 20,000 lines, but the quality of your product will be very low. And not because you didn’t have time to write unit tests, but because you didn’t know how to do it.</p><p>So every time I hear, “I didn’t have time for unit testing,” I understand that you just didn’t know how and are trying to conceal that fact behind false excuses. It’s not professional, to say the least.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>12 Best</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>All 292</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Webinars</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Talks</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Books</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Papers</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Pets</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html class=”highlighted”>Trainings</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Award</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Testimonials</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Shift-M</li> <li /2015/06/22/valid-reasons-to-reject-bug-fix.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/06/22/valid-reasons-to-reject-bug-fix.html</p><h1 itemprop="name headline mainEntityOfPage">A Few Valid Reasons to Reject a Bug Fix</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>A bug exists when something doesn’t work as expected. A bug fix is basically a patch (a pull request) to the existing code base that is supposed to solve the problem and make sure that “something” works as expected. Very often, such a patch fixes one thing and breaks many others. I believe that sometimes it’s necessary to reject a bug fix and ask its author to re-do the patch in order to protect the project from bigger problems. There are a few valid reasons for such a rejection, according to my experience.</p>
<figcaption id="3827b7b3">El Crimen Perfecto (2004) by Álex de la Iglesia</figcaption>
<figcaption id="3827b7b3">El Crimen Perfecto (2004) by Álex de la Iglesia</figcaption> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/06/18/good-programmers-bug-free.html>12 Best</li> <li /2015/06/18/good-programmers-bug-free.html>All 292</li> <li /2015/06/18/good-programmers-bug-free.html>Webinars</li> <li /2015/06/18/good-programmers-bug-free.html>Talks</li> <li /2015/06/18/good-programmers-bug-free.html>Books</li> <li /2015/06/18/good-programmers-bug-free.html>Papers</li> <li /2015/06/18/good-programmers-bug-free.html>Pets</li> <li /2015/06/18/good-programmers-bug-free.html class=”highlighted”>Trainings</li> <li /2015/06/18/good-programmers-bug-free.html>Award</li> <li /2015/06/18/good-programmers-bug-free.html>Testimonials</li> <li /2015/06/18/good-programmers-bug-free.html>Shift-M</li> <li /2015/06/18/good-programmers-bug-free.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/06/18/good-programmers-bug-free.html</p><h1 itemprop="name headline mainEntityOfPage">Good Programmers Write Bug-Free Code, Don’t They?</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="subline"> <li>Discussed at:</li> <li>reddit</li></ul><p class="unprintable"><p>Good programmers create fewer bugs while bad programmers cause more. Sounds logical, doesn’t it? However, there is a lot of criticism of this way of thinking. Take this one, for example: Bugs are inevitable, and instead of expecting fewer bugs from us, let us focus on the right design and let testers find and report bugs; then we’ll fix them. Or this one: Being afraid to make a mistake makes me write slower and experiment less, which translates into lower-quality software. Read more about that here and here. But allow me to look at this from a different perspective and assert that yes, indeed, good programmers create fewer bugs.</p>
<figcaption id="8a4f6549">Sabotage! (2000) by Esteban and Jose Miguel Ibarretxe</figcaption><figcaption id="8a4f6549">Sabotage! (2000) by Esteban and Jose Miguel Ibarretxe</figcaption> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/06/11/wikipedia-bug-definition.html>12 Best</li> <li /2015/06/11/wikipedia-bug-definition.html>All 292</li> <li /2015/06/11/wikipedia-bug-definition.html>Webinars</li> <li /2015/06/11/wikipedia-bug-definition.html>Talks</li> <li /2015/06/11/wikipedia-bug-definition.html>Books</li> <li /2015/06/11/wikipedia-bug-definition.html>Papers</li> <li /2015/06/11/wikipedia-bug-definition.html>Pets</li> <li /2015/06/11/wikipedia-bug-definition.html class=”highlighted”>Trainings</li> <li /2015/06/11/wikipedia-bug-definition.html>Award</li> <li /2015/06/11/wikipedia-bug-definition.html>Testimonials</li> <li /2015/06/11/wikipedia-bug-definition.html>Shift-M</li> <li /2015/06/11/wikipedia-bug-definition.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/06/11/wikipedia-bug-definition.html</p><h1 itemprop="name headline mainEntityOfPage">Wikipedia’s Definition of a Software Bug Is Wrong</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Here is what Wikipedia says at the time of this writing:</p><blockquote><p>A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result or to behave in unintended ways.</p></blockquote><p>I think that’s incomplete. The definition entirely excludes “non-behavioral” defects related to, for example, maintainability and reusability.</p><p>As you know, every piece of software has functional and non-functional requirements. Functional requirements tell us what the software has to do, and non-functional requirements document how it has to do it. For example, here is a functional requirement:</p>The user can generate a PDF report.</pre>PDF report generation must take less than 100ms.</pre>The source code of the PDF generator must be easy to maintain and extend for an average Java programmer.</pre>The user can generate a PDF report.</pre>PDF report generation must take less than 100ms.</pre>The source code of the PDF generator must be easy to maintain and extend for an average Java programmer.</pre> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/05/25/unit-test-scaffolding.html>12 Best</li> <li /2015/05/25/unit-test-scaffolding.html>All 292</li> <li /2015/05/25/unit-test-scaffolding.html>Webinars</li> <li /2015/05/25/unit-test-scaffolding.html>Talks</li> <li /2015/05/25/unit-test-scaffolding.html>Books</li> <li /2015/05/25/unit-test-scaffolding.html>Papers</li> <li /2015/05/25/unit-test-scaffolding.html>Pets</li> <li /2015/05/25/unit-test-scaffolding.html class=”highlighted”>Trainings</li> <li /2015/05/25/unit-test-scaffolding.html>Award</li> <li /2015/05/25/unit-test-scaffolding.html>Testimonials</li> <li /2015/05/25/unit-test-scaffolding.html>Shift-M</li> <li /2015/05/25/unit-test-scaffolding.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/05/25/unit-test-scaffolding.html</p><h1 itemprop="name headline mainEntityOfPage">A Few Thoughts on Unit Test Scaffolding</h1><ul class="subline"> <li> </li> <li class="desktop-only" itemprop="locationCreated">Atherton, CA</li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>When I start to repeat myself in unit test methods by creating the same objects and preparing the data to run the test, I feel disappointed in my design. Long test methods with a lot of code duplication just don’t look right. To simplify and shorten them, there are basically two options, at least in Java: 1) private properties initialized through @Before and @BeforeClass, and 2) private static methods. They both look anti-OOP to me, and I think there is an alternative. Let me explain.</p>
<figcaption id="6f716aac">Léon: The Professional by Luc Besson</figcaption>public final class MetricsTest { private File temp; private Folder folder; @Before public void prepare() { this.temp = Files.createTempDirectory("test"); this.folder = new DiscFolder(this.temp); this.folder.save("first.txt", "Hello, world!"); this.folder.save("second.txt", "Goodbye!"); } @After public void clean() { FileUtils.deleteDirectory(this.temp); } @Test public void calculatesTotalSize() { assertEquals(22, new Metrics(this.folder).size()); } @Test public void countsWordsInFiles() { assertEquals(4, new Metrics(this.folder).wc()); } }</pre>prepare(), it creates a “test fixture” of type Folder. That is used in all three tests as an argument for the Metrics constructor. The real class being tested here is Metrics while this.folder is something we need in order to test it.</p><aside class="youtube"> <div class="box"> 
<div class="play"></div></div><div>What Fake Objects Are For? (webinar #8); 4 November 2015.</div></aside><p>What’s wrong with this test? There is one serious issue: coupling between test methods. Test methods (and all tests in general) must be perfectly isolated from each other. This means that changing one test must not affect any others. In this example, that is not the case. When I want to change the countsWords() test, I have to change the internals of before(), which will affect the other method in the test “class.”</p><p>With all due respect to JUnit, the idea of creating test fixtures in @Before and @After is wrong, mostly because it encourages developers to couple test methods.</p><p>Here is how we can improve our test and isolate test methods:</p>public final class MetricsTest { @Test public void calculatesTotalSize() { final File dir = Files.createTempDirectory("test-1"); final Folder folder = MetricsTest.folder( dir, "first.txt:Hello, world!", "second.txt:Goodbye!" ); try { assertEquals(22, new Metrics(folder).size()); } finally { FileUtils.deleteDirectory(dir); } } @Test public void countsWordsInFiles() { final File dir = Files.createTempDirectory("test-2"); final Folder folder = MetricsTest.folder( dir, "alpha.txt:Three words here", "beta.txt:two words" "gamma.txt:one!" ); try { assertEquals(6, new Metrics(folder).wc()); } finally { FileUtils.deleteDirectory(dir); } } private static Folder folder(File dir, String... parts) { Folder folder = new DiscFolder(dir); for (final String part : parts) { final String[] pair = part.split(":", 2); this.folder.save(pair[0], pair[1]); } return folder; } }</pre>folder().</p><p>A utility method, huh? Yes, it smells.</p><p>The main issue with this design, even though it is way better than the previous one, is that it doesn’t prevent code duplication between test “classes.” If I need a similar test fixture of type Folder in another test case, I will have to move this static method there. Or even worse, I will have to create a utility class. Yes, there is nothing worse in object-oriented programming than utility classes.</p><p>A much better design would be to use “fake” objects instead of private static utilities. Here is how. First, we create a fake class and place it into src/main/java. This class can be used in tests and also in production code, if necessary (Fk for “fake”):</p>public final class FkFolder implements Folder, Closeable { private final File dir; private final String[] parts; public FkFolder(String... prts) { this(Files.createTempDirectory("test-1"), parts); } public FkFolder(File file, String... prts) { this.dir = file; this.parts = parts; } @Override public Iterable<File> files() { final Folder folder = new DiscFolder(this.dir); for (final String part : this.parts) { final String[] pair = part.split(":", 2); folder.save(pair[0], pair[1]); } return folder.files(); } @Override public void close() { FileUtils.deleteDirectory(this.dir); } }</pre>public final class MetricsTest { @Test public void calculatesTotalSize() { final String[] parts = { "first.txt:Hello, world!", "second.txt:Goodbye!" }; try (final Folder folder = new FkFolder(parts)) { assertEquals(22, new Metrics(folder).size()); } } @Test public void countsWordsInFiles() { final String[] parts = { "alpha.txt:Three words here", "beta.txt:two words" "gamma.txt:one!" }; try (final Folder folder = new FkFolder(parts)) { assertEquals(6, new Metrics(folder).wc()); } } }</pre>@Before and @BeforeClass, and 2) private static methods. They both look anti-OOP to me, and I think there is an alternative. Let me explain.</p><figcaption id="6f716aac">Léon: The Professional by Luc Besson</figcaption>public final class MetricsTest { private File temp; private Folder folder; @Before public void prepare() { this.temp = Files.createTempDirectory("test"); this.folder = new DiscFolder(this.temp); this.folder.save("first.txt", "Hello, world!"); this.folder.save("second.txt", "Goodbye!"); } @After public void clean() { FileUtils.deleteDirectory(this.temp); } @Test public void calculatesTotalSize() { assertEquals(22, new Metrics(this.folder).size()); } @Test public void countsWordsInFiles() { assertEquals(4, new Metrics(this.folder).wc()); } }</pre>prepare(), it creates a “test fixture” of type Folder. That is used in all three tests as an argument for the Metrics constructor. The real class being tested here is Metrics while this.folder is something we need in order to test it.</p><aside class="youtube"> <div class="box"> <div class="play"></div></div><div>What Fake Objects Are For? (webinar #8); 4 November 2015.</div></aside><p>What’s wrong with this test? There is one serious issue: coupling between test methods. Test methods (and all tests in general) must be perfectly isolated from each other. This means that changing one test must not affect any others. In this example, that is not the case. When I want to change the countsWords() test, I have to change the internals of before(), which will affect the other method in the test “class.”</p><p>With all due respect to JUnit, the idea of creating test fixtures in @Before and @After is wrong, mostly because it encourages developers to couple test methods.</p><p>Here is how we can improve our test and isolate test methods:</p>public final class MetricsTest { @Test public void calculatesTotalSize() { final File dir = Files.createTempDirectory("test-1"); final Folder folder = MetricsTest.folder( dir, "first.txt:Hello, world!", "second.txt:Goodbye!" ); try { assertEquals(22, new Metrics(folder).size()); } finally { FileUtils.deleteDirectory(dir); } } @Test public void countsWordsInFiles() { final File dir = Files.createTempDirectory("test-2"); final Folder folder = MetricsTest.folder( dir, "alpha.txt:Three words here", "beta.txt:two words" "gamma.txt:one!" ); try { assertEquals(6, new Metrics(folder).wc()); } finally { FileUtils.deleteDirectory(dir); } } private static Folder folder(File dir, String... parts) { Folder folder = new DiscFolder(dir); for (final String part : parts) { final String[] pair = part.split(":", 2); this.folder.save(pair[0], pair[1]); } return folder; } }</pre>folder().</p><p>A utility method, huh? Yes, it smells.</p><p>The main issue with this design, even though it is way better than the previous one, is that it doesn’t prevent code duplication between test “classes.” If I need a similar test fixture of type Folder in another test case, I will have to move this static method there. Or even worse, I will have to create a utility class. Yes, there is nothing worse in object-oriented programming than utility classes.</p><p>A much better design would be to use “fake” objects instead of private static utilities. Here is how. First, we create a fake class and place it into src/main/java. This class can be used in tests and also in production code, if necessary (Fk for “fake”):</p>public final class FkFolder implements Folder, Closeable { private final File dir; private final String[] parts; public FkFolder(String... prts) { this(Files.createTempDirectory("test-1"), parts); } public FkFolder(File file, String... prts) { this.dir = file; this.parts = parts; } @Override public Iterable<File> files() { final Folder folder = new DiscFolder(this.dir); for (final String part : this.parts) { final String[] pair = part.split(":", 2); folder.save(pair[0], pair[1]); } return folder.files(); } @Override public void close() { FileUtils.deleteDirectory(this.dir); } }</pre>public final class MetricsTest { @Test public void calculatesTotalSize() { final String[] parts = { "first.txt:Hello, world!", "second.txt:Goodbye!" }; try (final Folder folder = new FkFolder(parts)) { assertEquals(22, new Metrics(folder).size()); } } @Test public void countsWordsInFiles() { final String[] parts = { "alpha.txt:Three words here", "beta.txt:two words" "gamma.txt:one!" }; try (final Folder folder = new FkFolder(parts)) { assertEquals(6, new Metrics(folder).wc()); } } }</pre> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/05/07/ctors-must-be-code-free.html>12 Best</li> <li /2015/05/07/ctors-must-be-code-free.html>All 292</li> <li /2015/05/07/ctors-must-be-code-free.html>Webinars</li> <li /2015/05/07/ctors-must-be-code-free.html>Talks</li> <li /2015/05/07/ctors-must-be-code-free.html>Books</li> <li /2015/05/07/ctors-must-be-code-free.html>Papers</li> <li /2015/05/07/ctors-must-be-code-free.html>Pets</li> <li /2015/05/07/ctors-must-be-code-free.html class=”highlighted”>Trainings</li> <li /2015/05/07/ctors-must-be-code-free.html>Award</li> <li /2015/05/07/ctors-must-be-code-free.html>Testimonials</li> <li /2015/05/07/ctors-must-be-code-free.html>Shift-M</li> <li /2015/05/07/ctors-must-be-code-free.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/05/07/ctors-must-be-code-free.html</p><h1 itemprop="name headline mainEntityOfPage">Constructors Must Be Code-Free</h1><aside class='book'>Read more about this subject in Section 1.3of my book
</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>How much work should be done within a constructor? It seems reasonable to do some computations inside a constructor and then encapsulate results. That way, when the results are required by object methods, we’ll have them ready. Sounds like a good approach? No, it’s not. It’s a bad idea for one reason: It prevents composition of objects and makes them un-extensible.</p>
<figcaption id="780fae47">Kill Bill: Vol. 2 (2004) by Quentin Tarantino</figcaption>interface Name { String first(); }</pre>public final class EnglishName implements Name { private final String name; public EnglishName(final CharSequence text) { this.name = text.toString().split(" ", 2)[0]; } @Override public String first() { return this.name; } }</pre>first() method, it will return the same value and won’t need to do the splitting again. However, this is flawed thinking! Let me show you the right way and explain:</p>public final class EnglishName implements Name { private final CharSequence text; public EnglishName(final CharSequence txt) { this.text = txt; } @Override public String first() { return this.text.toString().split("", 2)[0]; } }</pre>
<div class="play"></div></div><div>A Few Thoughts About Constructors in OOP (webinar #7); 7 October 2015.</div></aside><p>In the first example, we are abusing the new operator and turning it into a static method, which does all calculations for us right here and now. This is what imperative programming is about. In imperative programming, we do all calculations right now and return fully ready results. In declarative programming, we are instead trying to delay calculations for as long as possible.</p><p>Let’s try to use our EnglishName class:</p>final Name name = new EnglishName( new NameInPostgreSQL(/*...*/) ); if (/* something goes wrong */) { throw new IllegalStateException( String.format( "Hi, %s, we can't proceed with your application", name.first() ) ); }</pre>name. We don’t want to go to the database yet and fetch the full name from there, split it into parts, and encapsulate them inside name. We just want to create an instance of an object. Such a parsing behavior would be a side effect for us and, in this case, will slow down the application. As you see, we may only need name.first() if something goes wrong and we need to construct an exception object.</p><p>My point is that having any computations done inside a constructor is a bad practice and must be avoided because they are side effects and are not requested by the object owner.</p><p>What about performance during the re-use of name, you may ask. If we make an instance of EnglishName and then call name.first() five times, we’ll end up with five calls to the String.split() method.</p><p>To solve that, we create another class, a composable decorator, which will help us solve this “re-use” problem:</p>public final class CachedName implements Name { private final Name origin; public CachedName(final Name name) { this.origin = name; } @Override @Cacheable(forever = true) public String first() { return this.origin.first(); } }</pre>Cacheable annotation from jcabi-aspects, but you can use any other caching tools available in Java (or other languages), like Guava Cache:</p>public final class CachedName implements Name { private final Cache<Long, String> cache = CacheBuilder.newBuilder().build(); private final Name origin; public CachedName(final Name name) { this.origin = name; } @Override public String first() { return this.cache.get( 1L, new Callable<String>() { @Override public String call() { return CachedName.this.origin.first(); } } ); } }</pre>CachedName mutable and lazily loaded—it’s an anti-pattern, which I’ve discussed before in Objects Should Be Immutable.</p><p>This is how our code will look now:</p>final Name name = new CachedName( new EnglishName( new NameInPostgreSQL(/*...*/) ) );</pre><figcaption id="780fae47">Kill Bill: Vol. 2 (2004) by Quentin Tarantino</figcaption>interface Name { String first(); }</pre>public final class EnglishName implements Name { private final String name; public EnglishName(final CharSequence text) { this.name = text.toString().split(" ", 2)[0]; } @Override public String first() { return this.name; } }</pre>first() method, it will return the same value and won’t need to do the splitting again. However, this is flawed thinking! Let me show you the right way and explain:</p>public final class EnglishName implements Name { private final CharSequence text; public EnglishName(final CharSequence txt) { this.text = txt; } @Override public String first() { return this.text.toString().split("", 2)[0]; } }</pre><div class="play"></div></div><div>A Few Thoughts About Constructors in OOP (webinar #7); 7 October 2015.</div></aside><p>In the first example, we are abusing the new operator and turning it into a static method, which does all calculations for us right here and now. This is what imperative programming is about. In imperative programming, we do all calculations right now and return fully ready results. In declarative programming, we are instead trying to delay calculations for as long as possible.</p><p>Let’s try to use our EnglishName class:</p>final Name name = new EnglishName( new NameInPostgreSQL(/*...*/) ); if (/* something goes wrong */) { throw new IllegalStateException( String.format( "Hi, %s, we can't proceed with your application", name.first() ) ); }</pre>name. We don’t want to go to the database yet and fetch the full name from there, split it into parts, and encapsulate them inside name. We just want to create an instance of an object. Such a parsing behavior would be a side effect for us and, in this case, will slow down the application. As you see, we may only need name.first() if something goes wrong and we need to construct an exception object.</p><p>My point is that having any computations done inside a constructor is a bad practice and must be avoided because they are side effects and are not requested by the object owner.</p><p>What about performance during the re-use of name, you may ask. If we make an instance of EnglishName and then call name.first() five times, we’ll end up with five calls to the String.split() method.</p><p>To solve that, we create another class, a composable decorator, which will help us solve this “re-use” problem:</p>public final class CachedName implements Name { private final Name origin; public CachedName(final Name name) { this.origin = name; } @Override @Cacheable(forever = true) public String first() { return this.origin.first(); } }</pre>Cacheable annotation from jcabi-aspects, but you can use any other caching tools available in Java (or other languages), like Guava Cache:</p>public final class CachedName implements Name { private final Cache<Long, String> cache = CacheBuilder.newBuilder().build(); private final Name origin; public CachedName(final Name name) { this.origin = name; } @Override public String first() { return this.cache.get( 1L, new Callable<String>() { @Override public String call() { return CachedName.this.origin.first(); } } ); } }</pre>CachedName mutable and lazily loaded—it’s an anti-pattern, which I’ve discussed before in Objects Should Be Immutable.</p><p>This is how our code will look now:</p>final Name name = new CachedName( new EnglishName( new NameInPostgreSQL(/*...*/) ) );</pre> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/04/30/iterating-adapter.html>12 Best</li> <li /2015/04/30/iterating-adapter.html>All 292</li> <li /2015/04/30/iterating-adapter.html>Webinars</li> <li /2015/04/30/iterating-adapter.html>Talks</li> <li /2015/04/30/iterating-adapter.html>Books</li> <li /2015/04/30/iterating-adapter.html>Papers</li> <li /2015/04/30/iterating-adapter.html>Pets</li> <li /2015/04/30/iterating-adapter.html class=”highlighted”>Trainings</li> <li /2015/04/30/iterating-adapter.html>Award</li> <li /2015/04/30/iterating-adapter.html>Testimonials</li> <li /2015/04/30/iterating-adapter.html>Shift-M</li> <li /2015/04/30/iterating-adapter.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/04/30/iterating-adapter.html</p><h1 itemprop="name headline mainEntityOfPage">How to Implement an Iterating Adapter</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Iterator is one of the fundamental Java interfaces, introduced in Java 1.2. It is supposed to be very simple; however, in my experience, many Java developers don’t understand how to implement a custom one, which should iterate a stream of data coming from some other source. In other words, it becomes an adapter of another source of data, in the form of an iterator. I hope this example will help.</p><p>Let’s say we have an object of this class:</p>final class Data { byte[] read(); }</pre>read(), it returns a new array of bytes that were retrieved from somewhere. If there is nothing to retrieve, the array will be empty. Now, we want to create an adapter that would consume the bytes and let us iterate them:</p>final class FluentData implements Iterator<Byte> { boolean hasNext() { /* ... */ } Byte next() { /* ... */ } void remove() { /* ... */ } }</pre>final class FluentData implements Iterator<Byte> { private final Data data; private final Queue<Byte> buffer = new LinkedList<>(); public FluentData(final Data dat) { this.data = dat; } public boolean hasNext() { if (this.buffer.isEmpty()) { for (final byte item : this.data.read()) { this.buffer.add(item); } } return !this.buffer.isEmpty(); } public Byte next() { if (!this.hasNext()) { throw new NoSuchElementException("Nothing left"); } return this.buffer.poll(); } public void remove() { throw new UnsupportedOperationException("It is read-only"); } }</pre>synchronized, this won’t guarantee that two threads won’t conflict when they both call hasNext() and next(). So don’t bother with it and just document the iterator as not thread-safe, then let its users synchronize one level higher when necessary.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Iterator is one of the fundamental Java interfaces, introduced in Java 1.2. It is supposed to be very simple; however, in my experience, many Java developers don’t understand how to implement a custom one, which should iterate a stream of data coming from some other source. In other words, it becomes an adapter of another source of data, in the form of an iterator. I hope this example will help.</p><p>Let’s say we have an object of this class:</p>final class Data { byte[] read(); }</pre>read(), it returns a new array of bytes that were retrieved from somewhere. If there is nothing to retrieve, the array will be empty. Now, we want to create an adapter that would consume the bytes and let us iterate them:</p>final class FluentData implements Iterator<Byte> { boolean hasNext() { /* ... */ } Byte next() { /* ... */ } void remove() { /* ... */ } }</pre>final class FluentData implements Iterator<Byte> { private final Data data; private final Queue<Byte> buffer = new LinkedList<>(); public FluentData(final Data dat) { this.data = dat; } public boolean hasNext() { if (this.buffer.isEmpty()) { for (final byte item : this.data.read()) { this.buffer.add(item); } } return !this.buffer.isEmpty(); } public Byte next() { if (!this.hasNext()) { throw new NoSuchElementException("Nothing left"); } return this.buffer.poll(); } public void remove() { throw new UnsupportedOperationException("It is read-only"); } }</pre>synchronized, this won’t guarantee that two threads won’t conflict when they both call hasNext() and next(). So don’t bother with it and just document the iterator as not thread-safe, then let its users synchronize one level higher when necessary.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/04/16/award.html>12 Best</li> <li /2015/04/16/award.html>All 292</li> <li /2015/04/16/award.html>Webinars</li> <li /2015/04/16/award.html>Talks</li> <li /2015/04/16/award.html>Books</li> <li /2015/04/16/award.html>Papers</li> <li /2015/04/16/award.html>Pets</li> <li /2015/04/16/award.html class=”highlighted”>Trainings</li> <li /2015/04/16/award.html>Award</li> <li /2015/04/16/award.html>Testimonials</li> <li /2015/04/16/award.html>Shift-M</li> <li /2015/04/16/award.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/04/16/award.html</p><h1 itemprop="name headline mainEntityOfPage">Software Quality Award, 2015</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable">
mdbs99/AWS</li> <li>FagnerMartinsBrack/WebStories</li> <li>robertop/triumph4php</li> <li>blambeau/wlang</li> <li>alf-tool/alf-core by @blambeau</li> <li>siom79/japicmp</li> <li>tunabrain/tungsten</li> <li>AdamsLair/duality</li> <li>openra/openra by @chrisforbes</li> <li>Pacmanfan/UVDLPSlicerController</li> <li>openfurther/further-open-core by @rahuofu</li> <li>Bertram25/ValyriaTear</li> <li>odoepner/typepad</li> <li>vladmihalcea/flexy-pool</li> <li>js-cookie/js-cookie by @FagnerMartinsBrack</li> <li>jOOQ/jOOQ by @lukaseder</li> <li>raphw/byte-buddy</li> <li>uniVocity/univocity-parsers by @jbax</li> <li>arnaudroger/SimpleFlatMapper</li> <li>elBukkit/MagicPlugin by @NathanWolf</li> <li>trade-manager/trade-manager</li> <li>ParaPenguin/morphix</li> <li>tzaeschke/zoodb</li> <li>tzaeschke/critbit</li> <li>praveendath92/MDroid</li> <li>DeqingSun/ESP8266-Dash-Button</li> <li>javamonkey/beetl2.0</li> <li>81813780/HandyTabBar</li> <li>xionghuiCoder/clearpool</li> <li>android-cjj/ComicReader</li> <li>Dreampie/icedog</li> <li>hujiaweibujidao/TinyWeibo</li> <li>hujiaweibujidao/XingShan</li> <li>hujiaweibujidao/WeChat4j</li> <li>beartung/tclip-android</li> <li>beartung/insta-filter</li> <li>wewoor/ZBLOG</li> <li>gulpjs/gulp by @contra</li> <li>joedayz/titanic-javaee7</li> <li>TheCricket/Chisel-2</li> <li>ddasilva/scheme-droid</li> <li>chenjishi/SlideActivity</li> <li>yazeed44/MultiImagePicker</li> <li>wbotelhos/raty</li> <li>miku-nyan/Overchan-Android</li> <li>chylex/Hardcore-Ender-Expansion</li> <li>lionsoul2014/jcseg</li> <li>yfpeng/pengyifan-bioc</li> <li>daimor/NBStudio</li> <li>sytolk/TaxiAndroidOpen</li> <li>yaylas/AndroidFaceRecognizer</li> <li>omgware/fluid-simulator-v2</li> <li>wendykierp/JTransforms</li> <li>zqq90/webit-script</li> <li>owasp/SecurityShepherd by @markdenihan</li> <li>subchen/jetbrick-template-2x</li> <li>subchen/snack-string</li> <li>restorer/gloomy-dungeons-2</li> <li>restorer/Gloomy-Dungeons-3D</li> <li>restorer/zame-haxe-particles</li> <li>mrzl/LeapMotionP5</li> <li>relu91/niftyeditor</li> <li>bparmentier/OpenBikeSharing</li> <li>graphhopper/graphhopper by @karussell</li> <li>t-oster/VisiCut</li> <li>arnaudroger/SimpleFlatMapper</li> <li>Floens/Clover</li> <li>chrisshayan/TechLooper</li> <li>bonigarcia/dualsub</li> <li>blundell/WoodyFaceDetection</li> <li>blundell/QuickSand</li> <li>blundell/ArrowLogger</li> <li>pushtorefresh/storio by @artem-zinnatullin</li> <li>mangstadt/ez-vcard</li> <li>jmyrland/DriSMo</li> <li>pmd/pmd by @adangel</li> <li>javaslang/javaslang</li> <li>thothbot/parallax</li> <li>jasonycw/MemeCreator</li> <li>jasonycw/TyphoonTycoon</li> <li>ysc/QuestionAnsweringSystem</li> <li>ysc/word</li> <li>andot/hprose</li> <li>guikeller/jetty-runner</li> <li>frizbog/gedcom4j</li> <li>h2oai/h2o-3 by @srisatish</li> <li>Feng14/MiniWeChat-Server</li> <li>tianzhijiexian/ActivityOptionsICS</li> <li>swanson/stringer</li> <li>JayFang1993/DropDownMenu</li> <li>AizazAZ/Android-Ultra-Photo-Selector</li> <li>patilswapnilv/TerminalIDE</li> <li>zhaoqp2010/andbase</li> <li>omry/banana</li> <li>jackrex/AndroidCacheFoundation</li> <li>kaitoy/pcap4j</li> <li>rgladwell/m2e-android</li> <li>scireum/parsii</li> <li>scireum/sirius-kernel</li> <li>yazeed44/ResizableView</li> <li>yazeed44/GroceryShopping</li> <li>MindMac/AndroidAppLog</li> <li>kpbird/chips-edittext-library</li> <li>spiffyui/spiffyui</li> <li>coala-analyzer/coala by @sils1297</li> <li>mgarin/weblaf</li> <li>conductor-framework/conductor by @ddavison</li> <li>ctron/package-drone</li> <li>markkerzner/FreeEed</li> <li>morris/lessql</li> <li>jitlogic/zorka</li> <li>sdorra/angular-dashboard-framework</li> <li>iluwatar/java-design-patterns</li> <li>chesterbr/ruby2600</li> <li>testinfected/molecule</li> <li>testinfected/simple-petstore</li> <li>pchab/AndroidRTC</li> <li>dolda2000/ashd</li> <li>MaigoAkisame/MCPDict</li> <li>Ph1b/MaterialAudiobookPlayer</li> <li>SVGKit/SVGKit by @adamgit</li> <li>vertigo17/Cerberus by @bcivel</li> <li>jaredsburrows/OpenQuartz</li> <li>jaredsburrows/AndroidGradleTemplate</li> <li>vitalidze/traccar-web</li> <li>ReikaKalseki/ChromatiCraft</li> <li>ReikaKalseki/RotaryCraft</li> <li>ReikaKalseki/DragonAPI</li> <li>jOOQ/jOOX by @lukaseder</li> <li>konsoletyper/teavm</li> <li>citiususc/hipster</li> <li>katzer/cordova-plugin-local-notifications</li> <li>katzer/cordova-plugin-background-mode</li> <li>katzer/cordova-plugin-email-composer</li> <li>nivdul/actitracker-cassandra-spark</li> <li>LuckyJayce/MVCHelper</li> <li>LuckyJayce/ViewPagerIndicator</li> <li>xvik/guice-persist-orient</li> <li>xvik/dropwizard-guicey</li> <li>mbosecke/pebble</li> <li>inklabs/kommerce-core by @pdt256</li> <li>elchris/easysql</li> <li>checkstyle/checkstyle by @romani</li> <li>mifmif/mspider</li> <li>mifmif/Generex</li> <li>KeldOelykke/FailFast</li> <li>erudika/para by @albogdano</li> <li>trautonen/coveralls-maven-plugin</li> <li>mystilleef/eclipse4-smartsave</li> <li>expercise/expercise by @ufukuzun</li> <li>kbilsted/StatePrinter</li> <li>js-cookie/java-cookie by @FagnerMartinsBrack</li> <li>Suseika/inflectible</li> <li>mp911de/lettuce</li> <li>hackiftekhar/IQKeyboardManager</li> <li>mafagafogigante/dungeon</li> <li>colonB/Mixer by @kkashpur</li> <li>colonB/Dorm by @kkashpur</li></ul><hr /><p></p><p>October, 4th: A few weeks ago I asked three guys, who work with me, to check every single project in this list and provide their feedback. I’ve received three plain text files from them. Here they are, combined into one, with almost no corrections: award-2015.txt (you can find your project there). Based on their opinions, I’ve decided to select the following 12 projects for closer review (in alphabetic order):</p><ul> <li>coala-analyzer/coala</li> <li>checkstyle/checkstyle</li> <li>citiususc/hipster</li> <li>gulpjs/gulp</li> <li>kaitoy/pcap4j</li> <li>raphw/byte-buddy (added on Oct-5)</li> <li>subchen/snack-string</li> <li>gvlasov/inflectible</li> <li>testinfected/molecule</li> <li>trautonen/coveralls-maven-plugin</li> <li>wbotelhos/raty</li> <li>xvik/guice-persist-orient</li></ul><p>I’ll review them soon. The winner will be announced on the 15th of October.</p><p>October, 5th: I received an email from the author of raphw/byte-buddy, asking me to reconsider my decision about this project. I took a quick look at why the project was filtered out and decided to include it into the list of finalists. BTW, if any of you think that your project was excluded by mistake, don’t hesitate to email me.</p><p>October, 11th: I analyzed all 12 projects today. All of them are really good projects, that’s why, in order to find the best one I was focusing on their sins, not virtues. Here is what I found, preliminary.</p><p>coala-analyzer/coala (14K Python LoC, 160K HoC)</p><ul> <li>None is used in many places (over 400 places I found), which technically is NULL, and it’s a serious anti-pattern</li> <li>There are global functions, for example get_language_tool_results and DictUtilities. It is definitely a bad idea in OOP.</li> <li>Class Constants is a terrible idea.</li> <li>Checking object types in runtime is a bad idea, e.g. ClangCountVectorCreator.py</li> <li>What’s wrong with cindex.py? There are almost 3200 lines of code, that’s way too many.</li> <li>Static analysis is not a mandatory step in the build/release pipeline. That’s why, I believe, code formatting is not consistent and sometimes rather ugly. For example, pylint reports hundreds of issues. (update: scrutinizer is used, but I still believe that a local use of pylint would seriously improve the quality of code)</li> <li>Some methods have documentation, others don’t. I didn’t understand the logic. Would be great to have all methods documented. Also, not all classes are documented.</li> <li>Score: 5</li></ul><p>checkstyle/checkstyle (83K Java LoC, 553K HoC)</p><ul> <li>There are many ER-ending classes, like SeverityLevelCounter, Filter, and AbstractLoader (for example), which are anti-patterns.</li> <li>There is a whole bunch of utility classes, which are definitely a bad thing in OOP. They are even grouped into a special utils package, such a terrible idea.</li> <li>Setters and getters are everywhere, together with immutable classes, which really are not an OOP thing, for example DetectorOptions.</li> <li>NULL is actively used, in many places—it’s a serious anti-pattern</li> <li>I’ve found five .java files with over 1000 lines in each of them, for example 2500+ in ParseTreeBuilder.java</li> <li>There are direct commits to master made by different contributors and some of them are not linked back to any tickets. It’s impossible to understand why they were made. Look at this for example: 7c50922. Was there a discussion involved? Who made a decision? Not clear at all.</li> <li>Releases are not documented at all.</li> <li>Release procedure is not automated. At least I didn’t find any release script in the repository.</li> <li>Score: 3</li></ul><p>citiususc/hipster (5K Java LoC, 64K HoC)</p><ul> <li>Getters and setters are used in many places, for example in DepthFirstSearch and Transition. Aside from that, almost all classes are mutable and are used as transfer bags for the needs of the algorithm. This is not how OOP should be used, I believe.</li> <li>There are public static methods and even utility classes, for example this one, with a funny name F</li> <li>NULL is used actively, especially in iterators—it’s a bad idea</li> <li>JavaDoc documentation is not consistent, some methods are documented, others aren’t.</li> <li>Not all commits are linked to tickets, look at this, for example: 8cfa5de.</li> <li>Changes are committed directly to master branch, pull requests are not used at all.</li> <li>I didn’t find an automated procedure for release. I found one for regular snapshot deployment to Bintray, but what about releases? Are they done manually?</li> <li>There is no static analysis, that’s why the code looks messy sometimes.</li> <li>The amount of unit tests is rather small. Besides that, I didn’t find a real code coverage report published anywhere.</li> <li>Score: 4</li></ul><p>gulpjs/gulp (700 JS LoC)</p><ul> <li>This project is too small for the competition, just 700 lines of code. Disqualified.</li> <li>Score: 0</li></ul><p>kaitoy/pcap4j (42K LoC, 122K HoC)</p><ul> <li>There is a util package with utility classes, which are a bad practice</li> <li>NULL is used in mutable objects, for example in AbstractPcapAddress; it’s a bad idea</li> <li>There too many static methods and variables. They are literally everywhere. There is even a module called pcap4j-packetfactory-static, full of “classes” with static methods.</li> <li>JavaDoc documentation is not consistent and sometimes just incomplete, check this, for example</li> <li>There are just a few issues and only six pull requests. Commits are not linked to issues. There is almost zero traceability of changes.</li> <li>Release procedure is not automated, releases are not documented</li> <li>There is no static analysis, that’s why the code looks messy sometimes</li> <li>Score: 3</li></ul><p>raphw/byte-buddy (84K LoC, 503K HoC)</p><ul> <li>I found over 20 .java files with over 1000 lines of code. TypePool.java even has 6200 lines!</li> <li>There are many public static methods and properties. I realize that maybe that the only way to deal with the problem domain in Java, but still…</li> <li>instanceof is used very often, and it’s a bad practice in OOP. Again, I understand that problem domain may require it sometimes, but still…</li> <li>Most commits are made directly to master, without pull requests or tickets, that’s why traceability of them is broken.</li> <li>Release procedure is not automated (I didn’t find a script).</li> <li>Score: 5</li></ul><p>subchen/snack-string (1K LoC, 2K HoC)</p><ul> <li>The project is too small, disqualified.</li> <li>Score: 0</li></ul><p>gvlasov/inflectible (5K LoC, 36K HoC)</p><ul> <li>The project is rather small, right on the edge of competition requirements and is made by a single developer. Besides that I don’t see any problems here. The code looks object oriented, all changes are traceable back to issues and pull requests, release procedure is automated, static analysis is mandatory, releases are documented. Thumbs up!</li> <li>Score: 10</li></ul><p>testinfected/molecule (10K LoC, 43K HoC)</p><ul> <li>There are a few utility classes, for example Streams</li> <li>There are setters and getters in some classes, even through they are in a different naming convention, for example Request and Response.</li> <li>Most of .java files don’t have any JavDoc blocks, and they look consistent, but then, all of a sudden, some files do have documentation, for example WebServer.</li> <li>There are not so many issues and most of commits are not traceable back to any of them, for example b4143a0—why it was made? Not clear. Also, there are almost no pull request. Looks like the author is just committing to master.</li> <li>Release procedure is not documented/automated. I didn’t find it. Also, releases are not documented at all.</li> <li>Static analysis is absent.</li> <li>Score: 6</li></ul><p>trautonen/coveralls-maven-plugin (4.5K LoC)</p><ul> <li>The project is too small for the competition, less than 5K lines of code. Besides that, it’s younger than one year, the first commit was made in May 2015. Disqualified.</li> <li>Score: 0</li></ul><p>wbotelhos/raty (8.7K LoC, 63K HoC)</p><ul> <li>There are utility classes, for example helper.js</li> <li>There are global functions, for example in helper.js</li> <li>jasmine.js has 2400 lines of code, which is way too many</li> <li>I didn’t understand why .html files stay together with .js in the same directory, for example run.html</li> <li>Not all changes are traceable to issues, for example 0a233e8. There are not so many issues in the project and just a few pull requests.</li> <li>Release procedure is not automated (at least I didn’t find any documentation about it)</li> <li>There is no static analysis</li> <li>There are no unit tests</li> <li>Score: 2</li></ul><p>xvik/guice-persist-orient (17K LoC, 54K HoC)</p><ul> <li>There is ORM and that’s why getters and setters, for example in VersionedEntity</li> <li>Dependency injection is actively used, which, I believe, is a bad idea in OOP in general. But in this project, I understand, it is required by the problem domain. Anyway…</li> <li>There are just a few issues and almost no pull requests, and commits are not traceable back to issues, for example this one: e9c8f79</li> <li>null, for example, much more seriously affected the score than the absence of an automated release procedure.</p><p>Oct 15: Thus, we have these best projects, out of 158 submitted to the competition:</p><ol> <li>gvlasov/inflectible: winner!</li> <li>testinfected/molecule</li> <li>coala-analyzer/coala</li> <li>xvik/guice-persist-orient</li> <li>raphw/byte-buddy</li> <li>citiususc/hipster</li> <li>checkstyle/checkstyle</li> <li>kaitoy/pcap4j</li> </ol><p>Congratulations to @gvlasov, the winner! Here is your badge:</p><p>
</p><p>Put this code into GitHub README:</p><a href="https://www.yegor256.com/2015/04/16/award.html"> <img src="//img.teamed.io/award/2015/winner.png" style="width:203px;height:45px;" alt='winner'/></a></pre>mdbs99/AWS</li> <li>FagnerMartinsBrack/WebStories</li> <li>robertop/triumph4php</li> <li>blambeau/wlang</li> <li>alf-tool/alf-core by @blambeau</li> <li>siom79/japicmp</li> <li>tunabrain/tungsten</li> <li>AdamsLair/duality</li> <li>openra/openra by @chrisforbes</li> <li>Pacmanfan/UVDLPSlicerController</li> <li>openfurther/further-open-core by @rahuofu</li> <li>Bertram25/ValyriaTear</li> <li>odoepner/typepad</li> <li>vladmihalcea/flexy-pool</li> <li>js-cookie/js-cookie by @FagnerMartinsBrack</li> <li>jOOQ/jOOQ by @lukaseder</li> <li>raphw/byte-buddy</li> <li>uniVocity/univocity-parsers by @jbax</li> <li>arnaudroger/SimpleFlatMapper</li> <li>elBukkit/MagicPlugin by @NathanWolf</li> <li>trade-manager/trade-manager</li> <li>ParaPenguin/morphix</li> <li>tzaeschke/zoodb</li> <li>tzaeschke/critbit</li> <li>praveendath92/MDroid</li> <li>DeqingSun/ESP8266-Dash-Button</li> <li>javamonkey/beetl2.0</li> <li>81813780/HandyTabBar</li> <li>xionghuiCoder/clearpool</li> <li>android-cjj/ComicReader</li> <li>Dreampie/icedog</li> <li>hujiaweibujidao/TinyWeibo</li> <li>hujiaweibujidao/XingShan</li> <li>hujiaweibujidao/WeChat4j</li> <li>beartung/tclip-android</li> <li>beartung/insta-filter</li> <li>wewoor/ZBLOG</li> <li>gulpjs/gulp by @contra</li> <li>joedayz/titanic-javaee7</li> <li>TheCricket/Chisel-2</li> <li>ddasilva/scheme-droid</li> <li>chenjishi/SlideActivity</li> <li>yazeed44/MultiImagePicker</li> <li>wbotelhos/raty</li> <li>miku-nyan/Overchan-Android</li> <li>chylex/Hardcore-Ender-Expansion</li> <li>lionsoul2014/jcseg</li> <li>yfpeng/pengyifan-bioc</li> <li>daimor/NBStudio</li> <li>sytolk/TaxiAndroidOpen</li> <li>yaylas/AndroidFaceRecognizer</li> <li>omgware/fluid-simulator-v2</li> <li>wendykierp/JTransforms</li> <li>zqq90/webit-script</li> <li>owasp/SecurityShepherd by @markdenihan</li> <li>subchen/jetbrick-template-2x</li> <li>subchen/snack-string</li> <li>restorer/gloomy-dungeons-2</li> <li>restorer/Gloomy-Dungeons-3D</li> <li>restorer/zame-haxe-particles</li> <li>mrzl/LeapMotionP5</li> <li>relu91/niftyeditor</li> <li>bparmentier/OpenBikeSharing</li> <li>graphhopper/graphhopper by @karussell</li> <li>t-oster/VisiCut</li> <li>arnaudroger/SimpleFlatMapper</li> <li>Floens/Clover</li> <li>chrisshayan/TechLooper</li> <li>bonigarcia/dualsub</li> <li>blundell/WoodyFaceDetection</li> <li>blundell/QuickSand</li> <li>blundell/ArrowLogger</li> <li>pushtorefresh/storio by @artem-zinnatullin</li> <li>mangstadt/ez-vcard</li> <li>jmyrland/DriSMo</li> <li>pmd/pmd by @adangel</li> <li>javaslang/javaslang</li> <li>thothbot/parallax</li> <li>jasonycw/MemeCreator</li> <li>jasonycw/TyphoonTycoon</li> <li>ysc/QuestionAnsweringSystem</li> <li>ysc/word</li> <li>andot/hprose</li> <li>guikeller/jetty-runner</li> <li>frizbog/gedcom4j</li> <li>h2oai/h2o-3 by @srisatish</li> <li>Feng14/MiniWeChat-Server</li> <li>tianzhijiexian/ActivityOptionsICS</li> <li>swanson/stringer</li> <li>JayFang1993/DropDownMenu</li> <li>AizazAZ/Android-Ultra-Photo-Selector</li> <li>patilswapnilv/TerminalIDE</li> <li>zhaoqp2010/andbase</li> <li>omry/banana</li> <li>jackrex/AndroidCacheFoundation</li> <li>kaitoy/pcap4j</li> <li>rgladwell/m2e-android</li> <li>scireum/parsii</li> <li>scireum/sirius-kernel</li> <li>yazeed44/ResizableView</li> <li>yazeed44/GroceryShopping</li> <li>MindMac/AndroidAppLog</li> <li>kpbird/chips-edittext-library</li> <li>spiffyui/spiffyui</li> <li>coala-analyzer/coala by @sils1297</li> <li>mgarin/weblaf</li> <li>conductor-framework/conductor by @ddavison</li> <li>ctron/package-drone</li> <li>markkerzner/FreeEed</li> <li>morris/lessql</li> <li>jitlogic/zorka</li> <li>sdorra/angular-dashboard-framework</li> <li>iluwatar/java-design-patterns</li> <li>chesterbr/ruby2600</li> <li>testinfected/molecule</li> <li>testinfected/simple-petstore</li> <li>pchab/AndroidRTC</li> <li>dolda2000/ashd</li> <li>MaigoAkisame/MCPDict</li> <li>Ph1b/MaterialAudiobookPlayer</li> <li>SVGKit/SVGKit by @adamgit</li> <li>vertigo17/Cerberus by @bcivel</li> <li>jaredsburrows/OpenQuartz</li> <li>jaredsburrows/AndroidGradleTemplate</li> <li>vitalidze/traccar-web</li> <li>ReikaKalseki/ChromatiCraft</li> <li>ReikaKalseki/RotaryCraft</li> <li>ReikaKalseki/DragonAPI</li> <li>jOOQ/jOOX by @lukaseder</li> <li>konsoletyper/teavm</li> <li>citiususc/hipster</li> <li>katzer/cordova-plugin-local-notifications</li> <li>katzer/cordova-plugin-background-mode</li> <li>katzer/cordova-plugin-email-composer</li> <li>nivdul/actitracker-cassandra-spark</li> <li>LuckyJayce/MVCHelper</li> <li>LuckyJayce/ViewPagerIndicator</li> <li>xvik/guice-persist-orient</li> <li>xvik/dropwizard-guicey</li> <li>mbosecke/pebble</li> <li>inklabs/kommerce-core by @pdt256</li> <li>elchris/easysql</li> <li>checkstyle/checkstyle by @romani</li> <li>mifmif/mspider</li> <li>mifmif/Generex</li> <li>KeldOelykke/FailFast</li> <li>erudika/para by @albogdano</li> <li>trautonen/coveralls-maven-plugin</li> <li>mystilleef/eclipse4-smartsave</li> <li>expercise/expercise by @ufukuzun</li> <li>kbilsted/StatePrinter</li> <li>js-cookie/java-cookie by @FagnerMartinsBrack</li> <li>Suseika/inflectible</li> <li>mp911de/lettuce</li> <li>hackiftekhar/IQKeyboardManager</li> <li>mafagafogigante/dungeon</li> <li>colonB/Mixer by @kkashpur</li> <li>colonB/Dorm by @kkashpur</li></ul><hr /><p></p><p>October, 4th: A few weeks ago I asked three guys, who work with me, to check every single project in this list and provide their feedback. I’ve received three plain text files from them. Here they are, combined into one, with almost no corrections: award-2015.txt (you can find your project there). Based on their opinions, I’ve decided to select the following 12 projects for closer review (in alphabetic order):</p><ul> <li>coala-analyzer/coala</li> <li>checkstyle/checkstyle</li> <li>citiususc/hipster</li> <li>gulpjs/gulp</li> <li>kaitoy/pcap4j</li> <li>raphw/byte-buddy (added on Oct-5)</li> <li>subchen/snack-string</li> <li>gvlasov/inflectible</li> <li>testinfected/molecule</li> <li>trautonen/coveralls-maven-plugin</li> <li>wbotelhos/raty</li> <li>xvik/guice-persist-orient</li></ul><p>I’ll review them soon. The winner will be announced on the 15th of October.</p><p>October, 5th: I received an email from the author of raphw/byte-buddy, asking me to reconsider my decision about this project. I took a quick look at why the project was filtered out and decided to include it into the list of finalists. BTW, if any of you think that your project was excluded by mistake, don’t hesitate to email me.</p><p>October, 11th: I analyzed all 12 projects today. All of them are really good projects, that’s why, in order to find the best one I was focusing on their sins, not virtues. Here is what I found, preliminary.</p><p>coala-analyzer/coala (14K Python LoC, 160K HoC)</p><ul> <li>None is used in many places (over 400 places I found), which technically is NULL, and it’s a serious anti-pattern</li> <li>There are global functions, for example get_language_tool_results and DictUtilities. It is definitely a bad idea in OOP.</li> <li>Class Constants is a terrible idea.</li> <li>Checking object types in runtime is a bad idea, e.g. ClangCountVectorCreator.py</li> <li>What’s wrong with cindex.py? There are almost 3200 lines of code, that’s way too many.</li> <li>Static analysis is not a mandatory step in the build/release pipeline. That’s why, I believe, code formatting is not consistent and sometimes rather ugly. For example, pylint reports hundreds of issues. (update: scrutinizer is used, but I still believe that a local use of pylint would seriously improve the quality of code)</li> <li>Some methods have documentation, others don’t. I didn’t understand the logic. Would be great to have all methods documented. Also, not all classes are documented.</li> <li>Score: 5</li></ul><p>checkstyle/checkstyle (83K Java LoC, 553K HoC)</p><ul> <li>There are many ER-ending classes, like SeverityLevelCounter, Filter, and AbstractLoader (for example), which are anti-patterns.</li> <li>There is a whole bunch of utility classes, which are definitely a bad thing in OOP. They are even grouped into a special utils package, such a terrible idea.</li> <li>Setters and getters are everywhere, together with immutable classes, which really are not an OOP thing, for example DetectorOptions.</li> <li>NULL is actively used, in many places—it’s a serious anti-pattern</li> <li>I’ve found five .java files with over 1000 lines in each of them, for example 2500+ in ParseTreeBuilder.java</li> <li>There are direct commits to master made by different contributors and some of them are not linked back to any tickets. It’s impossible to understand why they were made. Look at this for example: 7c50922. Was there a discussion involved? Who made a decision? Not clear at all.</li> <li>Releases are not documented at all.</li> <li>Release procedure is not automated. At least I didn’t find any release script in the repository.</li> <li>Score: 3</li></ul><p>citiususc/hipster (5K Java LoC, 64K HoC)</p><ul> <li>Getters and setters are used in many places, for example in DepthFirstSearch and Transition. Aside from that, almost all classes are mutable and are used as transfer bags for the needs of the algorithm. This is not how OOP should be used, I believe.</li> <li>There are public static methods and even utility classes, for example this one, with a funny name F</li> <li>NULL is used actively, especially in iterators—it’s a bad idea</li> <li>JavaDoc documentation is not consistent, some methods are documented, others aren’t.</li> <li>Not all commits are linked to tickets, look at this, for example: 8cfa5de.</li> <li>Changes are committed directly to master branch, pull requests are not used at all.</li> <li>I didn’t find an automated procedure for release. I found one for regular snapshot deployment to Bintray, but what about releases? Are they done manually?</li> <li>There is no static analysis, that’s why the code looks messy sometimes.</li> <li>The amount of unit tests is rather small. Besides that, I didn’t find a real code coverage report published anywhere.</li> <li>Score: 4</li></ul><p>gulpjs/gulp (700 JS LoC)</p><ul> <li>This project is too small for the competition, just 700 lines of code. Disqualified.</li> <li>Score: 0</li></ul><p>kaitoy/pcap4j (42K LoC, 122K HoC)</p><ul> <li>There is a util package with utility classes, which are a bad practice</li> <li>NULL is used in mutable objects, for example in AbstractPcapAddress; it’s a bad idea</li> <li>There too many static methods and variables. They are literally everywhere. There is even a module called pcap4j-packetfactory-static, full of “classes” with static methods.</li> <li>JavaDoc documentation is not consistent and sometimes just incomplete, check this, for example</li> <li>There are just a few issues and only six pull requests. Commits are not linked to issues. There is almost zero traceability of changes.</li> <li>Release procedure is not automated, releases are not documented</li> <li>There is no static analysis, that’s why the code looks messy sometimes</li> <li>Score: 3</li></ul><p>raphw/byte-buddy (84K LoC, 503K HoC)</p><ul> <li>I found over 20 .java files with over 1000 lines of code. TypePool.java even has 6200 lines!</li> <li>There are many public static methods and properties. I realize that maybe that the only way to deal with the problem domain in Java, but still…</li> <li>instanceof is used very often, and it’s a bad practice in OOP. Again, I understand that problem domain may require it sometimes, but still…</li> <li>Most commits are made directly to master, without pull requests or tickets, that’s why traceability of them is broken.</li> <li>Release procedure is not automated (I didn’t find a script).</li> <li>Score: 5</li></ul><p>subchen/snack-string (1K LoC, 2K HoC)</p><ul> <li>The project is too small, disqualified.</li> <li>Score: 0</li></ul><p>gvlasov/inflectible (5K LoC, 36K HoC)</p><ul> <li>The project is rather small, right on the edge of competition requirements and is made by a single developer. Besides that I don’t see any problems here. The code looks object oriented, all changes are traceable back to issues and pull requests, release procedure is automated, static analysis is mandatory, releases are documented. Thumbs up!</li> <li>Score: 10</li></ul><p>testinfected/molecule (10K LoC, 43K HoC)</p><ul> <li>There are a few utility classes, for example Streams</li> <li>There are setters and getters in some classes, even through they are in a different naming convention, for example Request and Response.</li> <li>Most of .java files don’t have any JavDoc blocks, and they look consistent, but then, all of a sudden, some files do have documentation, for example WebServer.</li> <li>There are not so many issues and most of commits are not traceable back to any of them, for example b4143a0—why it was made? Not clear. Also, there are almost no pull request. Looks like the author is just committing to master.</li> <li>Release procedure is not documented/automated. I didn’t find it. Also, releases are not documented at all.</li> <li>Static analysis is absent.</li> <li>Score: 6</li></ul><p>trautonen/coveralls-maven-plugin (4.5K LoC)</p><ul> <li>The project is too small for the competition, less than 5K lines of code. Besides that, it’s younger than one year, the first commit was made in May 2015. Disqualified.</li> <li>Score: 0</li></ul><p>wbotelhos/raty (8.7K LoC, 63K HoC)</p><ul> <li>There are utility classes, for example helper.js</li> <li>There are global functions, for example in helper.js</li> <li>jasmine.js has 2400 lines of code, which is way too many</li> <li>I didn’t understand why .html files stay together with .js in the same directory, for example run.html</li> <li>Not all changes are traceable to issues, for example 0a233e8. There are not so many issues in the project and just a few pull requests.</li> <li>Release procedure is not automated (at least I didn’t find any documentation about it)</li> <li>There is no static analysis</li> <li>There are no unit tests</li> <li>Score: 2</li></ul><p>xvik/guice-persist-orient (17K LoC, 54K HoC)</p><ul> <li>There is ORM and that’s why getters and setters, for example in VersionedEntity</li> <li>Dependency injection is actively used, which, I believe, is a bad idea in OOP in general. But in this project, I understand, it is required by the problem domain. Anyway…</li> <li>There are just a few issues and almost no pull requests, and commits are not traceable back to issues, for example this one: e9c8f79</li> <li>null, for example, much more seriously affected the score than the absence of an automated release procedure.</p><p>Oct 15: Thus, we have these best projects, out of 158 submitted to the competition:</p><ol> <li>gvlasov/inflectible: winner!</li> <li>testinfected/molecule</li> <li>coala-analyzer/coala</li> <li>xvik/guice-persist-orient</li> <li>raphw/byte-buddy</li> <li>citiususc/hipster</li> <li>checkstyle/checkstyle</li> <li>kaitoy/pcap4j</li> </ol><p>Congratulations to @gvlasov, the winner! Here is your badge:</p><p></p><p>Put this code into GitHub README:</p><a href="https://www.yegor256.com/2015/04/16/award.html"> <img src="//img.teamed.io/award/2015/winner.png" style="width:203px;height:45px;" alt='winner'/></a></pre> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/03/26/jaxb-vs-xembly.html>12 Best</li> <li /2015/03/26/jaxb-vs-xembly.html>All 292</li> <li /2015/03/26/jaxb-vs-xembly.html>Webinars</li> <li /2015/03/26/jaxb-vs-xembly.html>Talks</li> <li /2015/03/26/jaxb-vs-xembly.html>Books</li> <li /2015/03/26/jaxb-vs-xembly.html>Papers</li> <li /2015/03/26/jaxb-vs-xembly.html>Pets</li> <li /2015/03/26/jaxb-vs-xembly.html class=”highlighted”>Trainings</li> <li /2015/03/26/jaxb-vs-xembly.html>Award</li> <li /2015/03/26/jaxb-vs-xembly.html>Testimonials</li> <li /2015/03/26/jaxb-vs-xembly.html>Shift-M</li> <li /2015/03/26/jaxb-vs-xembly.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/03/26/jaxb-vs-xembly.html</p><h1 itemprop="name headline mainEntityOfPage">JAXB Is Doing It Wrong; Try Xembly</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable">
Book class that needs to be marshalled into an XML document. You have to create getters and annotate them:</p>import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement public class Book { private final String isbn; private final String title; public Book(final String isbn, final String title) { this.isbn = isbn; this.title = title; } @XmlElement public String getIsbn() { return this.isbn; } @XmlElement public String getTitle() { return this.title; } }</pre>Book into XML:</p>final Book book = new Book("0132350882", "Clean Code"); final JAXBContext context = JAXBContext.newInstance(Book.class); final Marshaller marshaller = jaxbContext.createMarshaller(); marshaller.marshal(book, System.out);</pre><?xml version="1.0"?> <book> <isbn>0132350882</isbn> <title>Clean Code</title> </book></pre>Book this way:</p>public class Book { private final String isbn; private final String title; public Book(final String isbn, final String title) { this.isbn = isbn; this.title = title; } public String toXML() { // create XML document and return } }</pre>toXML() method, we would have a big problem with duplicate code.</p><p>The second problem is that we don’t know exactly what type of wrapping our XML document should be delivered in. It may be a String or an InputStream or maybe an instance of org.w3c.dom.Document. Making many toXML() methods in each object would definitely be a disaster.</p><p>Xembly provides a solution. As I’ve mentioned before, it is an imperative language for XML constructions and manipulations. Here is how we can implement our Book object with the help of Xembly:</p>import org.xembly.Directive; public class Book { private final String isbn; private final String title; public Book(final String isbn, final String title) { this.isbn = isbn; this.title = title; } public Iterable<Directive> toXembly() { return new Directives() .add("book") .add("isbn").set(this.isbn).up() .add("title").set(this.title).up() .up(); } }</pre>final Book book = new Book("0132350882", "Clean Code"); final String xml = new Xembler(book.toXembly()).xml();</pre>Xembler class will convert Xembly directives into an XML document.</p><p>The beauty of this solution is that the internals of the object are not exposed via getters and the object is fully in charge of the XML marshalling process. In addition, the complexity of these directives may be very high—much higher than the rather cumbersome annotations of JAXB.</p><p>Xembly is an open source project, so feel free to submit your questions or corrections to GitHub.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div > Book class that needs to be marshalled into an XML document. You have to create getters and annotate them:</p>import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; @XmlRootElement public class Book { private final String isbn; private final String title; public Book(final String isbn, final String title) { this.isbn = isbn; this.title = title; } @XmlElement public String getIsbn() { return this.isbn; } @XmlElement public String getTitle() { return this.title; } }</pre>Book into XML:</p>final Book book = new Book("0132350882", "Clean Code"); final JAXBContext context = JAXBContext.newInstance(Book.class); final Marshaller marshaller = jaxbContext.createMarshaller(); marshaller.marshal(book, System.out);</pre><?xml version="1.0"?> <book> <isbn>0132350882</isbn> <title>Clean Code</title> </book></pre>Book this way:</p>public class Book { private final String isbn; private final String title; public Book(final String isbn, final String title) { this.isbn = isbn; this.title = title; } public String toXML() { // create XML document and return } }</pre>toXML() method, we would have a big problem with duplicate code.</p><p>The second problem is that we don’t know exactly what type of wrapping our XML document should be delivered in. It may be a String or an InputStream or maybe an instance of org.w3c.dom.Document. Making many toXML() methods in each object would definitely be a disaster.</p><p>Xembly provides a solution. As I’ve mentioned before, it is an imperative language for XML constructions and manipulations. Here is how we can implement our Book object with the help of Xembly:</p>import org.xembly.Directive; public class Book { private final String isbn; private final String title; public Book(final String isbn, final String title) { this.isbn = isbn; this.title = title; } public Iterable<Directive> toXembly() { return new Directives() .add("book") .add("isbn").set(this.isbn).up() .add("title").set(this.title).up() .up(); } }</pre>final Book book = new Book("0132350882", "Clean Code"); final String xml = new Xembler(book.toXembly()).xml();</pre>Xembler class will convert Xembly directives into an XML document.</p><p>The beauty of this solution is that the internals of the object are not exposed via getters and the object is fully in charge of the XML marshalling process. In addition, the complexity of these directives may be very high—much higher than the rather cumbersome annotations of JAXB.</p><p>Xembly is an open source project, so feel free to submit your questions or corrections to GitHub.</p></div></article></div><div class="wrapper"> </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/03/22/takes-java-web-framework.html>12 Best</li> <li /2015/03/22/takes-java-web-framework.html>All 292</li> <li /2015/03/22/takes-java-web-framework.html>Webinars</li> <li /2015/03/22/takes-java-web-framework.html>Talks</li> <li /2015/03/22/takes-java-web-framework.html>Books</li> <li /2015/03/22/takes-java-web-framework.html>Papers</li> <li /2015/03/22/takes-java-web-framework.html>Pets</li> <li /2015/03/22/takes-java-web-framework.html class=”highlighted”>Trainings</li> <li /2015/03/22/takes-java-web-framework.html>Award</li> <li /2015/03/22/takes-java-web-framework.html>Testimonials</li> <li /2015/03/22/takes-java-web-framework.html>Shift-M</li> <li /2015/03/22/takes-java-web-framework.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> https://www.yegor256.com/2015/03/22/takes-java-web-framework.html</p><h1 itemprop="name headline mainEntityOfPage">Java Web App Architecture In Takes Framework</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>I used to utilize Servlets, JSP, JAX-RS, Spring Framework, Play Framework, JSF with Facelets, and a bit of Spark Framework. All of these solutions, in my humble opinion, are very far from being object-oriented and elegant. They all are full of static methods, un-testable data structures, and dirty hacks. So about a month ago, I decided to create my own Java web framework. I put a few basic principles into its foundation: 1) No NULLs, 2) no public static methods, 3) no mutable classes, and 4) no class casting, reflection, and instanceof operators. These four basic principles should guarantee clean code and transparent architecture. That’s how the Takes framework was born. Let’s see what was created and how it works.</p>
<figcaption id="9fedcf46">Making of The Godfather (1972) by Francis Ford Coppola</figcaption>
<div class="play"></div></div><div>Takes, Java Web Framework, Intro (webinar #12); 2 March 2016.</div></aside><p>First, to create a web server, we should create a new network socket, that accepts connections on a certain TCP port. Usually it is 80, but I’m going to use 8080 for testing purposes. This is done in Java with the ServerSocket class:</p>import java.net.ServerSocket; public class Foo { public static void main(final String... args) throws Exception { final ServerSocket server = new ServerSocket(8080); while (true); } }</pre>http://localhost:8080 in their browser, the connection will be established and the browser will spin its waiting wheel forever. Compile this snippet and try. We just built a simple web server without the use of any frameworks. We’re not doing anything with incoming connections yet, but we’re not rejecting them either. All of them are being lined up inside that server object. It’s being done in a background thread; that’s why we need to put that while(true) in afterward. Without this endless pause, the app will finish its execution immediately and the server socket will shut down.</p><p>The next step is to accept the incoming connections. In Java, that’s done through a blocking call to the accept() method:</p>final Socket socket = server.accept();</pre>Socket. In order to accept the next connection, we should call accept() again. So basically, our web server should work like this:</p>public class Foo { public static void main(final String... args) throws Exception { final ServerSocket server = new ServerSocket(8080); while (true) { final Socket socket = server.accept(); // 1. Read HTTP request from the socket // 2. Prepare an HTTP response // 3. Send HTTP response to the socket // 4. Close the socket } } }</pre>final BufferedReader reader = new BufferedReader( new InputStreamReader(socket.getInputStream()) ); while (true) { final String line = reader.readLine(); if (line.isEmpty()) { break; } System.out.println(line); }</pre>GET / HTTP/1.1 Host: localhost:8080 Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8,ru;q=0.6,uk;q=0.4</pre>localhost, and as soon as the connection is ready, it immediately sends this text into it, then waits for a response.</p><p>Our job is to create an HTTP response using the information we get in the request. If our server is very primitive, we can basically ignore all the information in the request and just return “Hello, world!” to all requests (I’m using IOUtils for simplicity):</p>import java.net.Socket; import java.net.ServerSocket; import org.apache.commons.io.IOUtils; public class Foo { public static void main(final String... args) throws Exception { final ServerSocket server = new ServerSocket(8080); while (true) { try (final Socket socket = server.accept()) { IOUtils.copy( IOUtils.toInputStream("HTTP/1.1 200 OK\r\n\r\nHello, world!"), socket.getOutputStream() ); } } } }</pre>http://localhost:8080, and you will see Hello, world!:</p>$ javac -cp commons-io.jar Foo.java $ java -cp commons-io.jar:. Foo & $ curl http://localhost:8080 -v- Rebuilt URL to: http://localhost:8080/
- Connected to localhost (::1) port 8080 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.37.1 > Host: localhost:8080 > Accept: / > < HTTP/1.1 200 OK
- no chunk, no close, no size. Assume close to signal end <
- Closing connection 0 Hello, world!</code></pre></figure><p>That’s all you need to build a web server. Now let’s discuss how to make it object-oriented and composable. Let’s try to see how the Takes framework was built.</p><h2 id="routingdispatching">Routing/Dispatching</h2><p>Routing/dispatching is combined with response printing in Takes. All you need to do to create a working web application is to create a single class that implements
Takeinterface:</p><pre> <p>And now it’s time to start a server:</p>import org.takes.Request; import org.takes.Take; public final class TkFoo implements Take { @Override public Response route(final Request request) { return new RsText("Hello, world!"); } }</pre><pre> <p>Thisimport org.takes.http.Exit; import org.takes.http.FtBasic; public class Foo { public static void main(final String... args) throws Exception { new FtBasic(new TkFoo(), 8080).start(Exit.NEVER); } }</pre>FtBasicclass does the exact same socket manipulations explained above. It starts a server socket on port 8080 and dispatches all incoming connections through an instance ofTkFoothat we are giving to its constructor. It does this dispatching in an endless cycle, checking every second whether it’s time to stop with an instance ofExit. Obviously,Exit.NEVERalways responds with, “Don’t stop, please.”</p><h2 id="http-request">HTTP Request</h2><p>Now let’s see what’s inside the HTTP request arriving atTkFooand what we can get out of it. This is how theRequestinterface is defined in Takes:</p><pre> <p>The request is divided into two parts: the head and the body. The head contains all lines that go before the empty line that starts a body, according to HTTP specification in RFC 2616. There are many useful decorators forpublic interface Request { Iterable<String> head() throws IOException; InputStream body() throws IOException; }</pre>Requestin the framework. For example,RqMethodwill help you get the method name from the first line of the header:</p><pre> <p>final String method = new RqMethod(request).method();</pre>RqHrefwill help extract the query part and parse it. For example, this is the request:</p><pre> <p>This code will extract thatGET /user?id=123 HTTP/1.1 Host: www.example.com</pre>123:</p><pre> <p>final int id = Integer.parseInt( new RqHref(request).href().param("id").get(0) );</pre>RqPrintcan get the entire request or its body printed as aString:</p><pre> <p>The idea here is to keep thefinal String body = new RqPrint(request).printBody();</pre>Requestinterface simple and provide this request parsing functionality to its decorators. This approach helps the framework keep classes small and cohesive. Each decorator is very small and solid, doing exactly one thing. All of these decorators are in theorg.takes.rqpackage. As you already probably understand, theRqprefix stands forRequest.</p><h2 id="first-real-web-app">First Real Web App</h2><p>Let’s create our first real web application, which will do something useful. I would recommend starting with anEntryclass, which is required by Java to start an app from the command line:</p><pre> <p>This class contains just a singleimport org.takes.http.Exit; import org.takes.http.FtCli; public final class Entry { public static void main(final String... args) throws Exception { new FtCli(new TkApp(), args).start(Exit.NEVER); } }</pre>main()static method that will be called by JVM when the app starts from the command line. As you see, it instantiatesFtCli, giving it an instance of classTkAppand command line arguments. We’ll create theTkAppclass in a second.FtCli(translates to “front-end with command line interface”) makes an instance of the sameFtBasic, wrapping it into a few useful decorators and configuring it according to command line arguments. For example,--port=8080will be converted into a8080port number and passed as a second argument of theFtBasicconstructor.</p><p>The web application itself is calledTkAppand extendsTsWrap:</p><pre> <p>We’ll discuss thisimport org.takes.Take; import org.takes.facets.fork.FkRegex; import org.takes.facets.fork.TkFork; import org.takes.tk.TkWrap; import org.takes.tk.TkClasspath; final class TkApp extends TkWrap { TkApp() { super(TkApp.make()); } private static Take make() { return new TkFork( new FkRegex("/robots.txt", ""), new FkRegex("/css/.*", new TkClasspath()), new FkRegex("/", new TkIndex()) ); } }</pre>TkForkclass in a minute.</p><p>If you’re using Maven, this is thepom.xmlyou should start with:</p><pre> <p>Running<?xml version="1.0"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>foo</groupId> <artifactId>foo</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>org.takes</groupId> <artifactId>takes</artifactId> <version>0.9</version> <!-- check the latest in Maven Central --> </dependency> </dependencies> <build> <finalName>foo</finalName> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/deps</outputDirectory> </configuration> </execution> </executions> </plugin> </plugins> </build> </project></pre>mvn clean packageshould build afoo.jarfile intargetdirectory and a collection of all JAR dependencies intarget/deps. Now you can run the app from the command line:</p><pre> <p>The application is ready, and you can deploy it to, say, Heroku. Just create a$ mvn clean package $ java -Dfile.encoding=UTF-8 \ -cp ./target/foo.jar:./target/deps/* foo.Entry --port=8080</pre>Procfilefile in the root of the repository and push the repo to Heroku. This is whatProcfileshould look like:</p><pre> <h2 id="tkfork">web: java -Dfile.encoding=UTF-8 \ -cp target/foo.jar:target/deps/* \ foo.Entry --port=${PORT}</pre>TkFork</h2><p>ThisTkForkclass seems to be one of the core elements of the framework. It helps route an incoming HTTP request to the right take. Its logic is very simple, and there are just a few lines of code inside it. It encapsulates a collection of “forks,” which are instances of theForkinterface:</p><pre> <p>Its onlypublic interface Fork { Iterator<Response> route(Request req) throws IOException; }</pre>route()method either returns an empty iterator or an iterator with a singleResponse.TkForkgoes through all forks, calling theirroute()methods until one of them returns a response. Once that happens,TkForkreturns this response to the caller, which isFtBasic.</p><p>Let’s create a simple fork ourselves now. For example, we want to show the status of the application when the/statusURL is requested. Here is the code:</p><pre> <p>I believe the logic here is clear. We either return an empty iterator or an iterator with an instance offinal class TkApp extends TkWrap { private static Take make() { return new TkFork( new Fork() { @Override public Iterator<Response> route(Request req) { final Collection<Response> responses = new ArrayList<>(1); if (new RqHref(req).href().path().equals("/status")) { responses.add(new TkStatus()); } return responses.iterator(); } } ); } }</pre>TkStatusinside. If an empty iterator is returned,TkForkwill try to find another fork in the collection that actually gets an instance ofResponse. By the way, if nothing is found and all forks return empty iterators,TkForkwill throw a “Page not found” exception.</p><p>This exact logic is implemented by an out-of-the-box fork calledFkRegex, which attempts to match a request URI path with the regular expression provided:</p><pre> <p>We can compose a multi-level structure offinal class TkApp extends TkWrap { private static Take make() { return new TkFork( new FkRegex("/status", new TkStatus()) ); } }</pre>TkForkclasses; for example:</p><pre> <p>Again, I believe it’s obvious. The instance offinal class TkApp extends TsWrap { private static Take make() { return new TkFork( new FkRegex( "/status", new TkFork( new FkParams("f", "json", new TkStatusJSON()), new FkParams("f", "xml", new TkStatusXML()) ) ) ); } }</pre>FkRegexwill ask an encapsulated instance ofTkForkto return a response, and it will try to fetch it from one thatFkParamsencapsulated. If the HTTP query is/status?f=xml, an instance ofTkStatusXMLwill be returned.</p><h2 id="http-response">HTTP Response</h2><p>Now let’s discuss the structure of the HTTP response and its object-oriented abstraction,Response. This is how the interface looks:</p><pre> <p>Looks very similar to thepublic interface Response { Iterable<String> head() throws IOException; InputStream body() throws IOException; }</pre>Request, doesn’t it? Well, it’s identical, mostly because the structure of the HTTP request and response is almost identical. The only difference is the first line.</p><p>There is a collection of useful decorators that help in response building. They are composable, which makes them very convenient. For example, if you want to build a response that contains an HTML page, you compose them like this:</p><pre> <p>In this example, the decoratorfinal class TkIndex implements Take { @Override public Response act() { return new RsWithStatus( new RsWithType( new RsWithBody("<html>Hello, world!</html>"), "text/html" ), 200 ); } }</pre>RsWithBodycreates a response with a body but with no headers at all. Then,RsWithTypeadds the headerContent-Type: text/htmlto it. Then,RsWithStatusmakes sure the first line of the response containsHTTP/1.1 200 OK.</p><p>You can create your own decorators that can reuse existing ones. Take a look at how it’s done inRsPagefrom rultor.com.</p><h2 id="how-about-templates">How About Templates?</h2><p>Returning simple “Hello, world” pages is not a big problem, as we can see. But what about more complex output like HTML pages, XML documents, JSON data sets, etc? There are a few convenientResponsedecorators that enable all of that. Let’s start with Velocity, a simple templating engine. Well, it’s not that simple. It’s rather powerful, but I would suggest to use it in simple situations only. Here is how it works:</p><pre> <p>Thefinal class TkIndex implements Take { @Override public Response act() { return new RsVelocity("Hello, ${name}") .with("name", "Jeffrey"); } }</pre>RsVelocityconstructor accepts a single argument that has to be a Velocity template. Then, you call thewith()method, injecting data into the Velocity context. When it’s time to render the HTTP response,RsVelocitywill “evaluate” the template against the context configured. Again, I would recommend you use this templating approach only for simple outputs.</p><p>For more complex HTML documents, I would recommend you use XML/XSLT in combination with Xembly. I explained this idea in a few previous posts: XML+XSLT in a Browser and RESTful API and a Web Site in the Same URL. It is simple and powerful—Java generates XML output and the XSLT processor transforms it into HTML documents. This is how we separate representation from data. The XSL stylesheet is a “view” andTkIndexis a “controller,” in terms of MVC.</p><p>I’ll write a separate article about templating with Xembly and XSL very soon.</p><p>In the meantime, we’ll create decorators for JSF/Facelets and JSP rendering in Takes. If you’re interested in helping, please fork the framework and submit your pull requests.</p><h2 id="what-about-persistence">What About Persistence?</h2><p>Now, a question that comes up is what to do with persistent entities, like databases, in-memory structures, network connections, etc. My suggestion is to initialize them inside theEntryclass and pass them as arguments into theTkAppconstructor. Then, theTkAppwill pass them into the constructors of custom takes.</p><p>For example, we have a PostgreSQL database that contains some table data that we need to render. Here is how I would initialize a connection to it in theEntryclass (I’m using a BoneCP connection pool):</p><pre> <p>Now, the constructor ofpublic final class Entry { public static void main(final String... args) throws Exception { new FtCli(new TkApp(Entry.postgres()), args).start(Exit.NEVER); } private static Source postgres() { final BoneCPDataSource src = new BoneCPDataSource(); src.setDriverClass("org.postgresql.Driver"); src.setJdbcUrl("jdbc:postgresql://localhost/db"); src.setUser("root"); src.setPassword("super-secret-password"); return src; } }</pre>TkAppmust accept a single argument of typejava.sql.Source:</p><pre> <p>Classfinal class TkApp extends TkWrap { TkApp(final Source source) { super(TkApp.make(source)); } private static Take make(final Source source) { return new TkFork( new FkRegex("/", new TkIndex(source)) ); } }</pre>TkIndexalso accepts a single argument of classSource. I believe you know what to do with it insideTkIndexin order to fetch the SQL table data and convert it into HTML. The point here is that the dependency must be injected into the application (instance of classTkApp) at the moment of its instantiation. This is a pure and clean dependency injection mechanism, which is absolutely container-free. Read more about it in Dependency Injection Containers Are Code Polluters.</p><h2 id="unit-testing">Unit Testing</h2><p>Since every class is immutable and all dependencies are injected only through constructors, unit testing is extremely easy. Let’s say we want to testTkStatus, which is supposed to return an HTML response (I’m using JUnit 4 and Hamcrest):</p><pre> <p>Also, we can start the entire application or any individual take in a test HTTP server and test its behavior via a real TCP socket; for example (I’m using jcabi-http to make an HTTP request and check the output):</p>import org.junit.Test; import org.hamcrest.MatcherAssert; import org.hamcrest.Matchers; public final class TkIndexTest { @Test public void returnsHtmlPage() throws Exception { MatcherAssert.assertThat( new RsPrint( new TkStatus().act(new RqFake()) ).printBody(), Matchers.equalsTo("<html>Hello, world!</html>") ); } }</pre><pre> <p>public final class TkIndexTest { @Test public void returnsHtmlPage() throws Exception { new FtRemote(new TkIndex()).exec( new FtRemote.Script() { @Override public void exec(final URI home) throws IOException { new JdkRequest(home) .fetch() .as(RestResponse.class) .assertStatus(HttpURLConnection.HTTP_OK) .assertBody(Matchers.containsString("Hello, world!")); } } ); } }</pre>FtRemotestarts a test web server at a random TCP port and calls theexec()method at the provided instance ofFtRemote.Script. The first argument of this method is a URI of the just-started web server homepage.</p><p>The architecture of Takes framework is very modular and composable. Any individual take can be tested as a standalone component, absolutely independent from the framework and other takes.</p><h2 id="why-the-name">Why the Name?</h2><p>That’s the question I’ve been hearing rather often. The idea is simple, and it originates from the movie business. When a movie is made, the crew shoots many takes in order to capture the reality and put it on film. Each capture is called a take.</p><p>In other words, a take is like a snapshot of the reality.</p><p>The same applies to this framework. Each instance ofTakerepresents a reality at one particular moment in time. This reality is then sent to the user in the form of aResponse.</p><p>PS. There are a few words about authentication: How Cookie-Based Authentication Works in the Takes Framework.</p><p>PPS. There are a few real web systems, which you may be interested to take a look at. They all are using Takes Framework and their code is open: rultor.com, jare.io, wring.io.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>I used to utilize Servlets, JSP, JAX-RS, Spring Framework, Play Framework, JSF with Facelets, and a bit of Spark Framework. All of these solutions, in my humble opinion, are very far from being object-oriented and elegant. They all are full of static methods, un-testable data structures, and dirty hacks. So about a month ago, I decided to create my own Java web framework. I put a few basic principles into its foundation: 1) No NULLs, 2) no public static methods, 3) no mutable classes, and 4) no class casting, reflection, andinstanceofoperators. These four basic principles should guarantee clean code and transparent architecture. That’s how the Takes framework was born. Let’s see what was created and how it works.</p>ServerSocketclass:</p><pre> <p>That’s enough to start a web server. Now, the socket is ready and listening on port 8080. When someone opensimport java.net.ServerSocket; public class Foo { public static void main(final String... args) throws Exception { final ServerSocket server = new ServerSocket(8080); while (true); } }</pre>http://localhost:8080in their browser, the connection will be established and the browser will spin its waiting wheel forever. Compile this snippet and try. We just built a simple web server without the use of any frameworks. We’re not doing anything with incoming connections yet, but we’re not rejecting them either. All of them are being lined up inside thatserverobject. It’s being done in a background thread; that’s why we need to put thatwhile(true)in afterward. Without this endless pause, the app will finish its execution immediately and the server socket will shut down.</p><p>The next step is to accept the incoming connections. In Java, that’s done through a blocking call to theaccept()method:</p><pre> <p>The method is blocking its thread and waiting until a new connection arrives. As soon as that happens, it returns an instance offinal Socket socket = server.accept();</pre>Socket. In order to accept the next connection, we should callaccept()again. So basically, our web server should work like this:</p><pre> <p>It’s an endless cycle that accepts a new connection, understands it, creates a response, returns the response, and accepts a new connection again. HTTP protocol is stateless, which means the server should not remember what happened in any previous connection. All it cares about is the incoming HTTP request in this particular connection.</p><p>The HTTP request is coming from the input stream of the socket and looks like a multi-line block of text. This is what you would see if you read an input stream of the socket:</p>public class Foo { public static void main(final String... args) throws Exception { final ServerSocket server = new ServerSocket(8080); while (true) { final Socket socket = server.accept(); // 1. Read HTTP request from the socket // 2. Prepare an HTTP response // 3. Send HTTP response to the socket // 4. Close the socket } } }</pre><pre> <p>You will see something like this:</p>final BufferedReader reader = new BufferedReader( new InputStreamReader(socket.getInputStream()) ); while (true) { final String line = reader.readLine(); if (line.isEmpty()) { break; } System.out.println(line); }</pre><pre> <p>The client (the Google Chrome browser, for example) passes this text into the connection established. It connects to port 8080 atGET / HTTP/1.1 Host: localhost:8080 Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8,ru;q=0.6,uk;q=0.4</pre>localhost, and as soon as the connection is ready, it immediately sends this text into it, then waits for a response.</p><p>Our job is to create an HTTP response using the information we get in the request. If our server is very primitive, we can basically ignore all the information in the request and just return “Hello, world!” to all requests (I’m usingIOUtilsfor simplicity):</p><pre> <p>That’s it. The server is ready. Try to compile and run it. Point your browser toimport java.net.Socket; import java.net.ServerSocket; import org.apache.commons.io.IOUtils; public class Foo { public static void main(final String... args) throws Exception { final ServerSocket server = new ServerSocket(8080); while (true) { try (final Socket socket = server.accept()) { IOUtils.copy( IOUtils.toInputStream("HTTP/1.1 200 OK\r\n\r\nHello, world!"), socket.getOutputStream() ); } } } }</pre>http://localhost:8080, and you will seeHello, world!:</p><pre> $ javac -cp commons-io.jar Foo.java $ java -cp commons-io.jar:. Foo & $ curl http://localhost:8080 -v - Rebuilt URL to: http://localhost:8080/
- Connected to localhost (::1) port 8080 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.37.1 > Host: localhost:8080 > Accept: / > < HTTP/1.1 200 OK
- no chunk, no close, no size. Assume close to signal end <
- Closing connection 0 Hello, world!</code></pre></figure><p>That’s all you need to build a web server. Now let’s discuss how to make it object-oriented and composable. Let’s try to see how the Takes framework was built.</p><h2 id="routingdispatching">Routing/Dispatching</h2><p>Routing/dispatching is combined with response printing in Takes. All you need to do to create a working web application is to create a single class that implements
Takeinterface:</p><pre> <p>And now it’s time to start a server:</p>import org.takes.Request; import org.takes.Take; public final class TkFoo implements Take { @Override public Response route(final Request request) { return new RsText("Hello, world!"); } }</pre><pre> <p>Thisimport org.takes.http.Exit; import org.takes.http.FtBasic; public class Foo { public static void main(final String... args) throws Exception { new FtBasic(new TkFoo(), 8080).start(Exit.NEVER); } }</pre>FtBasicclass does the exact same socket manipulations explained above. It starts a server socket on port 8080 and dispatches all incoming connections through an instance ofTkFoothat we are giving to its constructor. It does this dispatching in an endless cycle, checking every second whether it’s time to stop with an instance ofExit. Obviously,Exit.NEVERalways responds with, “Don’t stop, please.”</p><h2 id="http-request">HTTP Request</h2><p>Now let’s see what’s inside the HTTP request arriving atTkFooand what we can get out of it. This is how theRequestinterface is defined in Takes:</p><pre> <p>The request is divided into two parts: the head and the body. The head contains all lines that go before the empty line that starts a body, according to HTTP specification in RFC 2616. There are many useful decorators forpublic interface Request { Iterable<String> head() throws IOException; InputStream body() throws IOException; }</pre>Requestin the framework. For example,RqMethodwill help you get the method name from the first line of the header:</p><pre> <p>final String method = new RqMethod(request).method();</pre>RqHrefwill help extract the query part and parse it. For example, this is the request:</p><pre> <p>This code will extract thatGET /user?id=123 HTTP/1.1 Host: www.example.com</pre>123:</p><pre> <p>final int id = Integer.parseInt( new RqHref(request).href().param("id").get(0) );</pre>RqPrintcan get the entire request or its body printed as aString:</p><pre> <p>The idea here is to keep thefinal String body = new RqPrint(request).printBody();</pre>Requestinterface simple and provide this request parsing functionality to its decorators. This approach helps the framework keep classes small and cohesive. Each decorator is very small and solid, doing exactly one thing. All of these decorators are in theorg.takes.rqpackage. As you already probably understand, theRqprefix stands forRequest.</p><h2 id="first-real-web-app">First Real Web App</h2><p>Let’s create our first real web application, which will do something useful. I would recommend starting with anEntryclass, which is required by Java to start an app from the command line:</p><pre> <p>This class contains just a singleimport org.takes.http.Exit; import org.takes.http.FtCli; public final class Entry { public static void main(final String... args) throws Exception { new FtCli(new TkApp(), args).start(Exit.NEVER); } }</pre>main()static method that will be called by JVM when the app starts from the command line. As you see, it instantiatesFtCli, giving it an instance of classTkAppand command line arguments. We’ll create theTkAppclass in a second.FtCli(translates to “front-end with command line interface”) makes an instance of the sameFtBasic, wrapping it into a few useful decorators and configuring it according to command line arguments. For example,--port=8080will be converted into a8080port number and passed as a second argument of theFtBasicconstructor.</p><p>The web application itself is calledTkAppand extendsTsWrap:</p><pre> <p>We’ll discuss thisimport org.takes.Take; import org.takes.facets.fork.FkRegex; import org.takes.facets.fork.TkFork; import org.takes.tk.TkWrap; import org.takes.tk.TkClasspath; final class TkApp extends TkWrap { TkApp() { super(TkApp.make()); } private static Take make() { return new TkFork( new FkRegex("/robots.txt", ""), new FkRegex("/css/.*", new TkClasspath()), new FkRegex("/", new TkIndex()) ); } }</pre>TkForkclass in a minute.</p><p>If you’re using Maven, this is thepom.xmlyou should start with:</p><pre> <p>Running<?xml version="1.0"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>foo</groupId> <artifactId>foo</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>org.takes</groupId> <artifactId>takes</artifactId> <version>0.9</version> <!-- check the latest in Maven Central --> </dependency> </dependencies> <build> <finalName>foo</finalName> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/deps</outputDirectory> </configuration> </execution> </executions> </plugin> </plugins> </build> </project></pre>mvn clean packageshould build afoo.jarfile intargetdirectory and a collection of all JAR dependencies intarget/deps. Now you can run the app from the command line:</p><pre> <p>The application is ready, and you can deploy it to, say, Heroku. Just create a$ mvn clean package $ java -Dfile.encoding=UTF-8 \ -cp ./target/foo.jar:./target/deps/* foo.Entry --port=8080</pre>Procfilefile in the root of the repository and push the repo to Heroku. This is whatProcfileshould look like:</p><pre> <h2 id="tkfork">web: java -Dfile.encoding=UTF-8 \ -cp target/foo.jar:target/deps/* \ foo.Entry --port=${PORT}</pre>TkFork</h2><p>ThisTkForkclass seems to be one of the core elements of the framework. It helps route an incoming HTTP request to the right take. Its logic is very simple, and there are just a few lines of code inside it. It encapsulates a collection of “forks,” which are instances of theForkinterface:</p><pre> <p>Its onlypublic interface Fork { Iterator<Response> route(Request req) throws IOException; }</pre>route()method either returns an empty iterator or an iterator with a singleResponse.TkForkgoes through all forks, calling theirroute()methods until one of them returns a response. Once that happens,TkForkreturns this response to the caller, which isFtBasic.</p><p>Let’s create a simple fork ourselves now. For example, we want to show the status of the application when the/statusURL is requested. Here is the code:</p><pre> <p>I believe the logic here is clear. We either return an empty iterator or an iterator with an instance offinal class TkApp extends TkWrap { private static Take make() { return new TkFork( new Fork() { @Override public Iterator<Response> route(Request req) { final Collection<Response> responses = new ArrayList<>(1); if (new RqHref(req).href().path().equals("/status")) { responses.add(new TkStatus()); } return responses.iterator(); } } ); } }</pre>TkStatusinside. If an empty iterator is returned,TkForkwill try to find another fork in the collection that actually gets an instance ofResponse. By the way, if nothing is found and all forks return empty iterators,TkForkwill throw a “Page not found” exception.</p><p>This exact logic is implemented by an out-of-the-box fork calledFkRegex, which attempts to match a request URI path with the regular expression provided:</p><pre> <p>We can compose a multi-level structure offinal class TkApp extends TkWrap { private static Take make() { return new TkFork( new FkRegex("/status", new TkStatus()) ); } }</pre>TkForkclasses; for example:</p><pre> <p>Again, I believe it’s obvious. The instance offinal class TkApp extends TsWrap { private static Take make() { return new TkFork( new FkRegex( "/status", new TkFork( new FkParams("f", "json", new TkStatusJSON()), new FkParams("f", "xml", new TkStatusXML()) ) ) ); } }</pre>FkRegexwill ask an encapsulated instance ofTkForkto return a response, and it will try to fetch it from one thatFkParamsencapsulated. If the HTTP query is/status?f=xml, an instance ofTkStatusXMLwill be returned.</p><h2 id="http-response">HTTP Response</h2><p>Now let’s discuss the structure of the HTTP response and its object-oriented abstraction,Response. This is how the interface looks:</p><pre> <p>Looks very similar to thepublic interface Response { Iterable<String> head() throws IOException; InputStream body() throws IOException; }</pre>Request, doesn’t it? Well, it’s identical, mostly because the structure of the HTTP request and response is almost identical. The only difference is the first line.</p><p>There is a collection of useful decorators that help in response building. They are composable, which makes them very convenient. For example, if you want to build a response that contains an HTML page, you compose them like this:</p><pre> <p>In this example, the decoratorfinal class TkIndex implements Take { @Override public Response act() { return new RsWithStatus( new RsWithType( new RsWithBody("<html>Hello, world!</html>"), "text/html" ), 200 ); } }</pre>RsWithBodycreates a response with a body but with no headers at all. Then,RsWithTypeadds the headerContent-Type: text/htmlto it. Then,RsWithStatusmakes sure the first line of the response containsHTTP/1.1 200 OK.</p><p>You can create your own decorators that can reuse existing ones. Take a look at how it’s done inRsPagefrom rultor.com.</p><h2 id="how-about-templates">How About Templates?</h2><p>Returning simple “Hello, world” pages is not a big problem, as we can see. But what about more complex output like HTML pages, XML documents, JSON data sets, etc? There are a few convenientResponsedecorators that enable all of that. Let’s start with Velocity, a simple templating engine. Well, it’s not that simple. It’s rather powerful, but I would suggest to use it in simple situations only. Here is how it works:</p><pre> <p>Thefinal class TkIndex implements Take { @Override public Response act() { return new RsVelocity("Hello, ${name}") .with("name", "Jeffrey"); } }</pre>RsVelocityconstructor accepts a single argument that has to be a Velocity template. Then, you call thewith()method, injecting data into the Velocity context. When it’s time to render the HTTP response,RsVelocitywill “evaluate” the template against the context configured. Again, I would recommend you use this templating approach only for simple outputs.</p><p>For more complex HTML documents, I would recommend you use XML/XSLT in combination with Xembly. I explained this idea in a few previous posts: XML+XSLT in a Browser and RESTful API and a Web Site in the Same URL. It is simple and powerful—Java generates XML output and the XSLT processor transforms it into HTML documents. This is how we separate representation from data. The XSL stylesheet is a “view” andTkIndexis a “controller,” in terms of MVC.</p><p>I’ll write a separate article about templating with Xembly and XSL very soon.</p><p>In the meantime, we’ll create decorators for JSF/Facelets and JSP rendering in Takes. If you’re interested in helping, please fork the framework and submit your pull requests.</p><h2 id="what-about-persistence">What About Persistence?</h2><p>Now, a question that comes up is what to do with persistent entities, like databases, in-memory structures, network connections, etc. My suggestion is to initialize them inside theEntryclass and pass them as arguments into theTkAppconstructor. Then, theTkAppwill pass them into the constructors of custom takes.</p><p>For example, we have a PostgreSQL database that contains some table data that we need to render. Here is how I would initialize a connection to it in theEntryclass (I’m using a BoneCP connection pool):</p><pre> <p>Now, the constructor ofpublic final class Entry { public static void main(final String... args) throws Exception { new FtCli(new TkApp(Entry.postgres()), args).start(Exit.NEVER); } private static Source postgres() { final BoneCPDataSource src = new BoneCPDataSource(); src.setDriverClass("org.postgresql.Driver"); src.setJdbcUrl("jdbc:postgresql://localhost/db"); src.setUser("root"); src.setPassword("super-secret-password"); return src; } }</pre>TkAppmust accept a single argument of typejava.sql.Source:</p><pre> <p>Classfinal class TkApp extends TkWrap { TkApp(final Source source) { super(TkApp.make(source)); } private static Take make(final Source source) { return new TkFork( new FkRegex("/", new TkIndex(source)) ); } }</pre>TkIndexalso accepts a single argument of classSource. I believe you know what to do with it insideTkIndexin order to fetch the SQL table data and convert it into HTML. The point here is that the dependency must be injected into the application (instance of classTkApp) at the moment of its instantiation. This is a pure and clean dependency injection mechanism, which is absolutely container-free. Read more about it in Dependency Injection Containers Are Code Polluters.</p><h2 id="unit-testing">Unit Testing</h2><p>Since every class is immutable and all dependencies are injected only through constructors, unit testing is extremely easy. Let’s say we want to testTkStatus, which is supposed to return an HTML response (I’m using JUnit 4 and Hamcrest):</p><pre> <p>Also, we can start the entire application or any individual take in a test HTTP server and test its behavior via a real TCP socket; for example (I’m using jcabi-http to make an HTTP request and check the output):</p>import org.junit.Test; import org.hamcrest.MatcherAssert; import org.hamcrest.Matchers; public final class TkIndexTest { @Test public void returnsHtmlPage() throws Exception { MatcherAssert.assertThat( new RsPrint( new TkStatus().act(new RqFake()) ).printBody(), Matchers.equalsTo("<html>Hello, world!</html>") ); } }</pre><pre> <p>public final class TkIndexTest { @Test public void returnsHtmlPage() throws Exception { new FtRemote(new TkIndex()).exec( new FtRemote.Script() { @Override public void exec(final URI home) throws IOException { new JdkRequest(home) .fetch() .as(RestResponse.class) .assertStatus(HttpURLConnection.HTTP_OK) .assertBody(Matchers.containsString("Hello, world!")); } } ); } }</pre>FtRemotestarts a test web server at a random TCP port and calls theexec()method at the provided instance ofFtRemote.Script. The first argument of this method is a URI of the just-started web server homepage.</p><p>The architecture of Takes framework is very modular and composable. Any individual take can be tested as a standalone component, absolutely independent from the framework and other takes.</p><h2 id="why-the-name">Why the Name?</h2><p>That’s the question I’ve been hearing rather often. The idea is simple, and it originates from the movie business. When a movie is made, the crew shoots many takes in order to capture the reality and put it on film. Each capture is called a take.</p><p>In other words, a take is like a snapshot of the reality.</p><p>The same applies to this framework. Each instance ofTakerepresents a reality at one particular moment in time. This reality is then sent to the user in the form of aResponse.</p><p>PS. There are a few words about authentication: How Cookie-Based Authentication Works in the Takes Framework.</p><p>PPS. There are a few real web systems, which you may be interested to take a look at. They all are using Takes Framework and their code is open: rultor.com, jare.io, wring.io.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> </div> </body> </html> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US" itemscope="" itemtype="http://schema.org/WebSite"> <head>
Composable Decorators vs. Imperative Utility Methods </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/02/26/composable-decorators.html>12 Best</li> <li /2015/02/26/composable-decorators.html>All 292</li> <li /2015/02/26/composable-decorators.html>Webinars</li> <li /2015/02/26/composable-decorators.html>Talks</li> <li /2015/02/26/composable-decorators.html>Books</li> <li /2015/02/26/composable-decorators.html>Papers</li> <li /2015/02/26/composable-decorators.html>Pets</li> <li /2015/02/26/composable-decorators.html class=”highlighted”>Trainings</li> <li /2015/02/26/composable-decorators.html>Award</li> <li /2015/02/26/composable-decorators.html>Testimonials</li> <li /2015/02/26/composable-decorators.html>Shift-M</li> <li /2015/02/26/composable-decorators.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/02/26/composable-decorators.html</p><h1 itemprop="name headline mainEntityOfPage">Composable Decorators vs. Imperative Utility Methods</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>The decorator pattern is my favorite among all other patterns I’m aware of. It is a very simple and yet very powerful mechanism to make your code highly cohesive and loosely coupled. However, I believe decorators are not used often enough. They should be everywhere, but they are not. The biggest advantage we get from decorators is that they make our code composable. That’s why the title of this post is composable decorators. Unfortunately, instead of decorators, we often use imperative utility methods, which make our code procedural rather than object-oriented.</p>
<pre> <p>Here is an implementation that reads the text from a file:</p>interface Text { String read(); }</pre><pre> <p>And now the decorator, which is another implementation offinal class TextInFile implements Text { private final File file; public TextInFile(final File src) { this.file = src; } @Override public String read() { return new String( Files.readAllBytes(this.file.toPath()), "UTF-8" ); } }</pre>Textthat removes all unprintable characters from the text:</p><pre> <p>Here is how I’m using it:</p>final class PrintableText implements Text { private final Text origin; public PrintableText(final Text text) { this.origin = text; } @Override public String read() { return this.origin.read() .replaceAll("[^\p{Print}]", ""); } }</pre><pre> <p>As you can see, thefinal Text text = new PrintableText( new TextInFile(new File("/tmp/a.txt")) ); String content = text.read();</pre>PrintableTextdoesn’t read the text from the file. It doesn’t really care where the text is coming from. It delegates text reading to the encapsulated instance ofText. How this encapsulated object will deal with the text and where it will get it doesn’t concernPrintableText.</p><p>Let’s continue and try to create an implementation ofTextthat will capitalize all letters in the text:</p><pre> <p>How about afinal class AllCapsText implements Text { private final Text origin; public AllCapsText(final Text text) { this.origin = text; } @Override public String read() { return this.origin.read().toUpperCase(Locale.ENGLISH); } }</pre>Textthat trims the input:</p><pre> <aside class="youtube"> <div class="box">final class TrimmedText implements Text { private final Text origin; public TrimmedText(final Text text) { this.origin = text; } @Override public String read() { return this.origin.read().trim(); } }</pre>
<div class="play"></div></div><div>Objects vs. Static Methods (webinar #1); 8 April 2015.</div></aside><p>I can go on and on with these decorators. I can create many of them, suitable for their own individual use cases. But let’s see how they all can play together. Let’s say I want to read the text from the file, capitalize it, trim it, and remove all unprintable characters. And I want to be declarative. Here is what I do:</p><pre> <p>First, I create an instance offinal Text text = new AllCapsText( new TrimmedText( new PrintableText( new TextInFile(new File("/tmp/a.txt")) ) ) ); String content = text.read();</pre>Text, composing multiple decorators into a single object. I declaratively define the behavior oftextwithout actually executing anything. Until methodread()is called, the file is not touched and the processing of the text is not started. The objecttextis just a composition of decorators, not an executable procedure. Check out this article about declarative and imperative styles of programming: Utility Classes Have Nothing to Do With Functional Programming.</p><p>This design is much more flexible and reusable than a more traditional one, where theTextobject is smart enough to perform all said operations. For example, classStringfrom Java is a good example of a bad design. It has more than 20 utility methods that should have been provided as decorators instead:trim(),toUpperCase(),substring(),split(), and many others, for example. When I want to trim my string, uppercase it, and then split it into pieces, here is what my code will look like:</p><pre> <p>This is imperative and procedural programming. Composable decorators, on the other hand, would make this code object-oriented and declarative. Something like this would be great to have in Java instead (pseudo-code):</p>final String txt = "hello, world!"; final String[] parts = txt.trim().toUpperCase().split(" ");</pre><pre> <p>To conclude, I recommend you think twice every time you add a new utility method to the interface/class. Try to avoid utility methods as much as possible, and use decorators instead. An ideal interface should contain only methods that you absolutely cannot remove. Everything else should be done through composable decorators.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>The decorator pattern is my favorite among all other patterns I’m aware of. It is a very simple and yet very powerful mechanism to make your code highly cohesive and loosely coupled. However, I believe decorators are not used often enough. They should be everywhere, but they are not. The biggest advantage we get from decorators is that they make our code composable. That’s why the title of this post is composable decorators. Unfortunately, instead of decorators, we often use imperative utility methods, which make our code procedural rather than object-oriented.</p>final String[] parts = new String.Split( new String.UpperCased( new String.Trimmed("hello, world!") ) );</pre><pre> <p>Here is an implementation that reads the text from a file:</p>interface Text { String read(); }</pre><pre> <p>And now the decorator, which is another implementation offinal class TextInFile implements Text { private final File file; public TextInFile(final File src) { this.file = src; } @Override public String read() { return new String( Files.readAllBytes(this.file.toPath()), "UTF-8" ); } }</pre>Textthat removes all unprintable characters from the text:</p><pre> <p>Here is how I’m using it:</p>final class PrintableText implements Text { private final Text origin; public PrintableText(final Text text) { this.origin = text; } @Override public String read() { return this.origin.read() .replaceAll("[^\p{Print}]", ""); } }</pre><pre> <p>As you can see, thefinal Text text = new PrintableText( new TextInFile(new File("/tmp/a.txt")) ); String content = text.read();</pre>PrintableTextdoesn’t read the text from the file. It doesn’t really care where the text is coming from. It delegates text reading to the encapsulated instance ofText. How this encapsulated object will deal with the text and where it will get it doesn’t concernPrintableText.</p><p>Let’s continue and try to create an implementation ofTextthat will capitalize all letters in the text:</p><pre> <p>How about afinal class AllCapsText implements Text { private final Text origin; public AllCapsText(final Text text) { this.origin = text; } @Override public String read() { return this.origin.read().toUpperCase(Locale.ENGLISH); } }</pre>Textthat trims the input:</p><pre> <aside class="youtube"> <div class="box">final class TrimmedText implements Text { private final Text origin; public TrimmedText(final Text text) { this.origin = text; } @Override public String read() { return this.origin.read().trim(); } }</pre><div class="play"></div></div><div>Objects vs. Static Methods (webinar #1); 8 April 2015.</div></aside><p>I can go on and on with these decorators. I can create many of them, suitable for their own individual use cases. But let’s see how they all can play together. Let’s say I want to read the text from the file, capitalize it, trim it, and remove all unprintable characters. And I want to be declarative. Here is what I do:</p><pre> <p>First, I create an instance offinal Text text = new AllCapsText( new TrimmedText( new PrintableText( new TextInFile(new File("/tmp/a.txt")) ) ) ); String content = text.read();</pre>Text, composing multiple decorators into a single object. I declaratively define the behavior oftextwithout actually executing anything. Until methodread()is called, the file is not touched and the processing of the text is not started. The objecttextis just a composition of decorators, not an executable procedure. Check out this article about declarative and imperative styles of programming: Utility Classes Have Nothing to Do With Functional Programming.</p><p>This design is much more flexible and reusable than a more traditional one, where theTextobject is smart enough to perform all said operations. For example, classStringfrom Java is a good example of a bad design. It has more than 20 utility methods that should have been provided as decorators instead:trim(),toUpperCase(),substring(),split(), and many others, for example. When I want to trim my string, uppercase it, and then split it into pieces, here is what my code will look like:</p><pre> <p>This is imperative and procedural programming. Composable decorators, on the other hand, would make this code object-oriented and declarative. Something like this would be great to have in Java instead (pseudo-code):</p>final String txt = "hello, world!"; final String[] parts = txt.trim().toUpperCase().split(" ");</pre><pre> <p>To conclude, I recommend you think twice every time you add a new utility method to the interface/class. Try to avoid utility methods as much as possible, and use decorators instead. An ideal interface should contain only methods that you absolutely cannot remove. Everything else should be done through composable decorators.</p></div></article></div><div class="wrapper">final String[] parts = new String.Split( new String.UpperCased( new String.Trimmed("hello, world!") ) );</pre></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> A Haircut </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/02/23/haircut.html>12 Best</li> <li /2015/02/23/haircut.html>All 292</li> <li /2015/02/23/haircut.html>Webinars</li> <li /2015/02/23/haircut.html>Talks</li> <li /2015/02/23/haircut.html>Books</li> <li /2015/02/23/haircut.html>Papers</li> <li /2015/02/23/haircut.html>Pets</li> <li /2015/02/23/haircut.html class=”highlighted”>Trainings</li> <li /2015/02/23/haircut.html>Award</li> <li /2015/02/23/haircut.html>Testimonials</li> <li /2015/02/23/haircut.html>Shift-M</li> <li /2015/02/23/haircut.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/02/23/haircut.html</p><h1 itemprop="name headline mainEntityOfPage">A Haircut</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>I received a haircut today, and the niceness of my hairdresser led him to fill the appointment with courteous questions about how I wanted my hair cut, what size of clipper he should use, how long the sides should be, and how much should be removed from the front. He also offered me many types of shampoo and a cup of tea. All this reminded me of the work we do as programmers, and I decided to write a short post about it. I’ve already mentioned before that trying to make a customer happy is a false objective. This hairdresser was a perfect illustrative example of this very mistake. By the way, in the end, I wasn’t happy, and he got no tip. How could this happen if he was so friendly and nice?</p>
<figcaption id="243d0d7c">The Man Who Wasn't There (2001) by Coen Brothers</figcaption></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Utility Classes Have Nothing to Do With Functional Programming </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>12 Best</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>All 292</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Webinars</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Talks</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Books</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Papers</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Pets</li> <li /2015/02/20/utility-classes-vs-functional-programming.html class=”highlighted”>Trainings</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Award</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Testimonials</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Shift-M</li> <li /2015/02/20/utility-classes-vs-functional-programming.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/02/20/utility-classes-vs-functional-programming.html</p><h1 itemprop="name headline mainEntityOfPage">Utility Classes Have Nothing to Do With Functional Programming</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>I was recently accused of being against functional programming because I call utility classes an anti-pattern. That’s absolutely wrong! Well, I do consider them a terrible anti-pattern, but they have nothing to do with functional programming. I believe there are two basic reasons why. First, functional programming is declarative, while utility class methods are imperative. Second, functional programming is based on lambda calculus, where a function can be assigned to a variable. Utility class methods are not functions in this sense. I’ll decode these statements in a minute.</p><p>In Java, there are basically two valid alternatives to these ugly utility classes aggressively promoted by Guava, Apache Commons, and others. The first one is the use of traditional classes, and the second one is Java 8 lambda. Now let’s see why utility classes are not even close to functional programming and where this misconception is coming from.</p>
<figcaption id="56d1f92f">Color Me Kubrick (2005) by Brian W. Cook</figcaption>Mathfrom Java 1.0:</p><pre> <p>Here is how you would use it when you want to calculate an absolute value of a floating point number:</p>public class Math { public static double abs(double a); // a few dozens of other methods of the same style }</pre><pre> <aside class="quote">The code will work, but it is not object-oriented programming</aside><p>What’s wrong with it? We need a function, and we get it from classdouble x = Math.abs(3.1415926d);</pre>Math. The class has many useful functions inside it that can be used for many typical mathematical operations, like calculating maximum, minimum, sine, cosine, etc. It is a very popular concept; just look at any commercial or open source product. These utility classes are used everywhere since Java was invented (thisMathclass was introduced in Java’s first version). Well, technically there is nothing wrong. The code will work. But it is not object-oriented programming. Instead, it is imperative and procedural. Do we care? Well, it’s up to you to decide. Let’s see what the difference is.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Objects vs. Static Methods (webinar #1); 8 April 2015.</div></aside><p>There are basically two different approaches: declarative and imperative.</p><p>Imperative programming is focused on describing how a program operates in terms of statements that change a program state. We just saw an example of imperative programming above. Here is another (this is pure imperative/procedural programming that has nothing to do with OOP):</p><pre> <p>Declarative programming focuses on what the program should accomplish without prescribing how to do it in terms of sequences of actions to be taken. This is how the same code would look in Lisp, a functional programming language:</p>public class MyMath { public double f(double a, double b) { double max = Math.max(a, b); double x = Math.abs(max); return x; } }</pre><pre> <p>What’s the catch? Just a difference in syntax? Not really.</p><p>There are many definitions of the difference between imperative and declarative styles, but I will try to give my own. There are basically three roles interacting in the scenario with this(defun f (a b) (abs (max a b)))</pre>ffunction/method: a buyer, a packager of the result, and a consumer of the result. Let’s say I call this function like this:</p><pre> <p>Here, methodpublic void foo() { double x = this.calc(5, -7); System.out.println("max+abs equals to " + x); } private double calc(double a, double b) { double x = Math.f(a, b); return x; }</pre>calc()is a buyer, methodMath.f()is a packager of the result, and methodfoo()is a consumer. No matter which programming style is used, there are always these three guys participating in the process: the buyer, the packager, and the consumer.</p><aside class="youtube"> <div class="box">
<div class="play"></div></div><div>What’s Wrong About Utility Classes? (webinar #6); 2 September 2015.</div></aside><p>Imagine you’re a buyer and want to purchase a gift for your (girl|boy)friend. The first option is to visit a shop, pay $50, let them package that perfume for you, and then deliver it to the friend (and get a kiss in return). This is an imperative style.</p><p>The second option is to visit a shop, pay $50, and get a gift card. You then present this card to the friend (and get a kiss in return). When he or she decides to convert it to perfume, he or she will visit the shop and get it. This is a declarative style.</p><p>See the difference?</p><p>In the first case, which is imperative, you force the packager (a beauty shop) to find that perfume in stock, package it, and present it to you as a ready-to-be-used product. In the second scenario, which is declarative, you’re just getting a promise from the shop that eventually, when it’s necessary, the staff will find the perfume in stock, package it, and provide it to those who need it. If your friend never visits the shop with that gift card, the perfume will remain in stock.</p><p>Moreover, your friend can use that gift card as a product itself, never visiting the shop. He or she may instead present it to somebody else as a gift or just exchange it for another card or product. The gift card itself becomes a product!</p><p>So the difference is what the consumer is getting—either a product ready to be used (imperative) or a voucher for the product, which can later be converted into a real product (declarative).</p><p>Utility classes, like Mathfrom JDK orStringUtilsfrom Apache Commons, return products ready to be used immediately, while functions in Lisp and other functional languages return “vouchers.” For example, if you call themaxfunction in Lisp, the actual maximum between two numbers will only be calculated when you actually start using it:</p><pre> <p>Until this(let (x (max 1 5)) (print "X equals to " x))</pre>printactually starts to output characters to the screen, the functionmaxwon’t be called. Thisxis a “voucher” returned to you when you attempted to “buy” a maximum between1and5.</p><p>Note, however, that nesting Java static functions one into another doesn’t make them declarative. The code is still imperative, because its execution delivers the result here and now:</p><pre> <p>“Okay,” you may say, “I got it, but why is declarative style better than imperative? What’s the big deal?” I’m getting to it. Let me first show the difference between functions in functional programming and static methods in OOP. As mentioned above, this is the second big difference between utility classes and functional programming.</p><p>In any functional programming language, you can do this:</p>public class MyMath { public double f(double a, double b) { return Math.abs(Math.max(a, b)); } }</pre><pre> <p>Then, later, you can call that(defun foo (x) (x 5))</pre>x:</p><pre> <p>Static methods in Java are not functions in terms of functional programming. You can’t do anything like this with a static method. You can’t pass a static method as an argument to another method. Basically, static methods are procedures or, simply put, Java statements grouped under a unique name. The only way to access them is to call a procedure and pass all necessary arguments to it. The procedure will calculate something and return a result that is immediately ready for usage.</p><p>And now we’re getting to the final question I can hear you asking: “Okay, utility classes are not functional programming, but they look like functional programming, they work very fast, and they are very easy to use. Why not use them? Why aim for perfection when 20 years of Java history proves that utility classes are the main instrument of each Java developer?”</p><p>Besides OOP fundamentalism, which I’m very often accused of, there are a few very practical reasons (BTW, I am an OOP fundamentalist):</p><ul> <li><p>Testability. Calls to static methods in utility classes are hard-coded dependencies that can never be broken for testing purposes. If your class is calling(defun bar (x) (+ x 1)) // defining function bar (print (foo bar)) // passing bar as an argument to foo</pre>FileUtils.readFile(), I will never be able to test it without using a real file on disk.</p></li> <li><p>Efficiency. Utility classes, due to their imperative nature, are much less efficient than their declarative alternatives. They simply do all calculations right here and now, taking processor resources even when it’s not yet necessary. Instead of returning a promise to break down a string into chunks,StringUtils.split()breaks it down right now. And it breaks it down into all possible chunks, even if only the first one is required by the “buyer.”</p></li> <li><p>Readability. Utility classes tend to be huge (try to read the source code ofStringUtilsorFileUtilsfrom Apache Commons). The entire idea of separation of concerns, which makes OOP so beautiful, is absent in utility classes. They just put all possible procedures into one huge.javafile, which becomes absolutely unmaintainable when it surpasses a dozen static methods.</p></li></ul><p>To conclude, let me reiterate: Utility classes have nothing to do with functional programming. They are simply bags of static methods, which are imperative procedures. Try to stay as far as possible away from them and use solid, cohesive objects no matter how many of them you have to declare and how small they are.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>I was recently accused of being against functional programming because I call utility classes an anti-pattern. That’s absolutely wrong! Well, I do consider them a terrible anti-pattern, but they have nothing to do with functional programming. I believe there are two basic reasons why. First, functional programming is declarative, while utility class methods are imperative. Second, functional programming is based on lambda calculus, where a function can be assigned to a variable. Utility class methods are not functions in this sense. I’ll decode these statements in a minute.</p><p>In Java, there are basically two valid alternatives to these ugly utility classes aggressively promoted by Guava, Apache Commons, and others. The first one is the use of traditional classes, and the second one is Java 8 lambda. Now let’s see why utility classes are not even close to functional programming and where this misconception is coming from.</p>Mathfrom Java 1.0:</p><pre> <p>Here is how you would use it when you want to calculate an absolute value of a floating point number:</p>public class Math { public static double abs(double a); // a few dozens of other methods of the same style }</pre><pre> <aside class="quote">The code will work, but it is not object-oriented programming</aside><p>What’s wrong with it? We need a function, and we get it from classdouble x = Math.abs(3.1415926d);</pre>Math. The class has many useful functions inside it that can be used for many typical mathematical operations, like calculating maximum, minimum, sine, cosine, etc. It is a very popular concept; just look at any commercial or open source product. These utility classes are used everywhere since Java was invented (thisMathclass was introduced in Java’s first version). Well, technically there is nothing wrong. The code will work. But it is not object-oriented programming. Instead, it is imperative and procedural. Do we care? Well, it’s up to you to decide. Let’s see what the difference is.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Objects vs. Static Methods (webinar #1); 8 April 2015.</div></aside><p>There are basically two different approaches: declarative and imperative.</p><p>Imperative programming is focused on describing how a program operates in terms of statements that change a program state. We just saw an example of imperative programming above. Here is another (this is pure imperative/procedural programming that has nothing to do with OOP):</p><pre> <p>Declarative programming focuses on what the program should accomplish without prescribing how to do it in terms of sequences of actions to be taken. This is how the same code would look in Lisp, a functional programming language:</p>public class MyMath { public double f(double a, double b) { double max = Math.max(a, b); double x = Math.abs(max); return x; } }</pre><pre> <p>What’s the catch? Just a difference in syntax? Not really.</p><p>There are many definitions of the difference between imperative and declarative styles, but I will try to give my own. There are basically three roles interacting in the scenario with this(defun f (a b) (abs (max a b)))</pre>ffunction/method: a buyer, a packager of the result, and a consumer of the result. Let’s say I call this function like this:</p><pre> <p>Here, methodpublic void foo() { double x = this.calc(5, -7); System.out.println("max+abs equals to " + x); } private double calc(double a, double b) { double x = Math.f(a, b); return x; }</pre>calc()is a buyer, methodMath.f()is a packager of the result, and methodfoo()is a consumer. No matter which programming style is used, there are always these three guys participating in the process: the buyer, the packager, and the consumer.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>What’s Wrong About Utility Classes? (webinar #6); 2 September 2015.</div></aside><p>Imagine you’re a buyer and want to purchase a gift for your (girl|boy)friend. The first option is to visit a shop, pay $50, let them package that perfume for you, and then deliver it to the friend (and get a kiss in return). This is an imperative style.</p><p>The second option is to visit a shop, pay $50, and get a gift card. You then present this card to the friend (and get a kiss in return). When he or she decides to convert it to perfume, he or she will visit the shop and get it. This is a declarative style.</p><p>See the difference?</p><p>In the first case, which is imperative, you force the packager (a beauty shop) to find that perfume in stock, package it, and present it to you as a ready-to-be-used product. In the second scenario, which is declarative, you’re just getting a promise from the shop that eventually, when it’s necessary, the staff will find the perfume in stock, package it, and provide it to those who need it. If your friend never visits the shop with that gift card, the perfume will remain in stock.</p><p>Moreover, your friend can use that gift card as a product itself, never visiting the shop. He or she may instead present it to somebody else as a gift or just exchange it for another card or product. The gift card itself becomes a product!</p><p>So the difference is what the consumer is getting—either a product ready to be used (imperative) or a voucher for the product, which can later be converted into a real product (declarative).</p><p>Utility classes, like Mathfrom JDK orStringUtilsfrom Apache Commons, return products ready to be used immediately, while functions in Lisp and other functional languages return “vouchers.” For example, if you call themaxfunction in Lisp, the actual maximum between two numbers will only be calculated when you actually start using it:</p><pre> <p>Until this(let (x (max 1 5)) (print "X equals to " x))</pre>printactually starts to output characters to the screen, the functionmaxwon’t be called. Thisxis a “voucher” returned to you when you attempted to “buy” a maximum between1and5.</p><p>Note, however, that nesting Java static functions one into another doesn’t make them declarative. The code is still imperative, because its execution delivers the result here and now:</p><pre> <p>“Okay,” you may say, “I got it, but why is declarative style better than imperative? What’s the big deal?” I’m getting to it. Let me first show the difference between functions in functional programming and static methods in OOP. As mentioned above, this is the second big difference between utility classes and functional programming.</p><p>In any functional programming language, you can do this:</p>public class MyMath { public double f(double a, double b) { return Math.abs(Math.max(a, b)); } }</pre><pre> <p>Then, later, you can call that(defun foo (x) (x 5))</pre>x:</p><pre> <p>Static methods in Java are not functions in terms of functional programming. You can’t do anything like this with a static method. You can’t pass a static method as an argument to another method. Basically, static methods are procedures or, simply put, Java statements grouped under a unique name. The only way to access them is to call a procedure and pass all necessary arguments to it. The procedure will calculate something and return a result that is immediately ready for usage.</p><p>And now we’re getting to the final question I can hear you asking: “Okay, utility classes are not functional programming, but they look like functional programming, they work very fast, and they are very easy to use. Why not use them? Why aim for perfection when 20 years of Java history proves that utility classes are the main instrument of each Java developer?”</p><p>Besides OOP fundamentalism, which I’m very often accused of, there are a few very practical reasons (BTW, I am an OOP fundamentalist):</p><ul> <li><p>Testability. Calls to static methods in utility classes are hard-coded dependencies that can never be broken for testing purposes. If your class is calling(defun bar (x) (+ x 1)) // defining function bar (print (foo bar)) // passing bar as an argument to foo</pre>FileUtils.readFile(), I will never be able to test it without using a real file on disk.</p></li> <li><p>Efficiency. Utility classes, due to their imperative nature, are much less efficient than their declarative alternatives. They simply do all calculations right here and now, taking processor resources even when it’s not yet necessary. Instead of returning a promise to break down a string into chunks,StringUtils.split()breaks it down right now. And it breaks it down into all possible chunks, even if only the first one is required by the “buyer.”</p></li> <li><p>Readability. Utility classes tend to be huge (try to read the source code ofStringUtilsorFileUtilsfrom Apache Commons). The entire idea of separation of concerns, which makes OOP so beautiful, is absent in utility classes. They just put all possible procedures into one huge.javafile, which becomes absolutely unmaintainable when it surpasses a dozen static methods.</p></li></ul><p>To conclude, let me reiterate: Utility classes have nothing to do with functional programming. They are simply bags of static methods, which are imperative procedures. Try to stay as far as possible away from them and use solid, cohesive objects no matter how many of them you have to declare and how small they are.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Code For the User, Not for Yourself </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/02/12/top-down-design.html>12 Best</li> <li /2015/02/12/top-down-design.html>All 292</li> <li /2015/02/12/top-down-design.html>Webinars</li> <li /2015/02/12/top-down-design.html>Talks</li> <li /2015/02/12/top-down-design.html>Books</li> <li /2015/02/12/top-down-design.html>Papers</li> <li /2015/02/12/top-down-design.html>Pets</li> <li /2015/02/12/top-down-design.html class=”highlighted”>Trainings</li> <li /2015/02/12/top-down-design.html>Award</li> <li /2015/02/12/top-down-design.html>Testimonials</li> <li /2015/02/12/top-down-design.html>Shift-M</li> <li /2015/02/12/top-down-design.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/02/12/top-down-design.html</p><h1 itemprop="name headline mainEntityOfPage">Code For the User, Not for Yourself</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>First, no matter what the methodology is, we all write software for our users (a.k.a. customers, project sponsors, end users, or clients). Second, no matter what the methodology is, we write incrementally, releasing features and bug fixes one by one. Maybe I’m saying something absolutely obvious here, but it’s important to remember that each new version should first of all satisfy the needs of the user, not of us programmers. In other words, the way we decompose a big task into smaller pieces should be user-targeted, and that’s why you always work top down. Let’s see what I mean through a practical example.</p>
<figcaption id="077c7d62">Delicatessen (1991) by Jean-Pierre Jeunet</figcaption><pre> <p>But let’s be professional and not forget about build automation and unit testing. Here is a simple#include <stdio.h> #include <unistd.h> int main() { char ch; int count = 0; while (1) { if (read(STDIN_FILENO, &ch, 1) <= 0) { break; } if (ch == ' ') { ++count; } } if (count > 0) { ++count; } printf("%d\n", count); return 0; }</pre>Makefilethat does them both:</p><pre> <p>Now I runall: wc test wc: wc.c gcc -o wc wc.c test: wc echo '' | ./wc | grep '0' echo 'Hello, world! How are you?' | ./wc | grep '5'</pre>makefrom a command line and get this output:</p><pre> <p>All clean!</p><p>I’m ready to get my $200. Wait, the deal was to deliver two versions and get cash in two installments. Let’s back up a little and think—how can we break this small tool into two parts?</p><p>On first thought, let’s release the tool itself first and build automation and testing next. Is that a good idea? Can we deliver any software without running it first with a test? How can I be sure that it works if I don’t ship tests together with it? What will my friend think about me releasing anything without tests? This would be a total embarrassment.</p><p>Okay, let’s release$ make echo '' | ./wc | grep '0' 0 echo 'Hello, world! How are you?' | ./wc | grep '5' 5</pre>Makefilefirst andwc.cnext. But what will my friend do with a couple of tests and no product in hand? This first release will be absolutely pointless, and I won’t get my $100.</p><aside class="quote">Every new increment must add some value to the product as it is perceived by the customer, not by us programmers</aside><p>Now we’re getting to the point of this article. What I’m trying to say is that every new increment must add some value to the product as it is perceived by the customer, not by us programmers. TheMakefileis definitely a valuable artifact, but it provides no value to my friend. He doesn’t need it, but I need it.</p><p>Here is what I’m going to do. I’ll release a skeleton of the tool, backed by the tests but with an absolutely dummy implementation. Look at it:</p><pre> <p>And I will modify the#include <stdio.h> int main() { printf("5\n"); return 0; }</pre>Makefileaccordingly. I will disable the first test to make sure the build passes.</p><p>Does my tool work? Yes, it does. Does it count words? Yes, it does for some inputs. Does it have value to my friend. Obviously! He can run it from the command line, and he can pass a file as an input. He will always get number “5” as a result of counting, though. That’s a bummer, but it’s an alpha version. He doesn’t expect it to work perfectly.</p><p>However, it works, it is backed by tests, and it is properly packaged.</p><p>What I just did is a top-down approach to design. First of all, I created something that provides value to my customer. I made sure it also satisfies my technical objectives, like proper unit test coverage and build automation. But the most important goal for me was to make sure my friend received something … and paid me.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>First, no matter what the methodology is, we all write software for our users (a.k.a. customers, project sponsors, end users, or clients). Second, no matter what the methodology is, we write incrementally, releasing features and bug fixes one by one. Maybe I’m saying something absolutely obvious here, but it’s important to remember that each new version should first of all satisfy the needs of the user, not of us programmers. In other words, the way we decompose a big task into smaller pieces should be user-targeted, and that’s why you always work top down. Let’s see what I mean through a practical example.</p><pre> <p>But let’s be professional and not forget about build automation and unit testing. Here is a simple#include <stdio.h> #include <unistd.h> int main() { char ch; int count = 0; while (1) { if (read(STDIN_FILENO, &ch, 1) <= 0) { break; } if (ch == ' ') { ++count; } } if (count > 0) { ++count; } printf("%d\n", count); return 0; }</pre>Makefilethat does them both:</p><pre> <p>Now I runall: wc test wc: wc.c gcc -o wc wc.c test: wc echo '' | ./wc | grep '0' echo 'Hello, world! How are you?' | ./wc | grep '5'</pre>makefrom a command line and get this output:</p><pre> <p>All clean!</p><p>I’m ready to get my $200. Wait, the deal was to deliver two versions and get cash in two installments. Let’s back up a little and think—how can we break this small tool into two parts?</p><p>On first thought, let’s release the tool itself first and build automation and testing next. Is that a good idea? Can we deliver any software without running it first with a test? How can I be sure that it works if I don’t ship tests together with it? What will my friend think about me releasing anything without tests? This would be a total embarrassment.</p><p>Okay, let’s release$ make echo '' | ./wc | grep '0' 0 echo 'Hello, world! How are you?' | ./wc | grep '5' 5</pre>Makefilefirst andwc.cnext. But what will my friend do with a couple of tests and no product in hand? This first release will be absolutely pointless, and I won’t get my $100.</p><aside class="quote">Every new increment must add some value to the product as it is perceived by the customer, not by us programmers</aside><p>Now we’re getting to the point of this article. What I’m trying to say is that every new increment must add some value to the product as it is perceived by the customer, not by us programmers. TheMakefileis definitely a valuable artifact, but it provides no value to my friend. He doesn’t need it, but I need it.</p><p>Here is what I’m going to do. I’ll release a skeleton of the tool, backed by the tests but with an absolutely dummy implementation. Look at it:</p><pre> <p>And I will modify the#include <stdio.h> int main() { printf("5\n"); return 0; }</pre>Makefileaccordingly. I will disable the first test to make sure the build passes.</p><p>Does my tool work? Yes, it does. Does it count words? Yes, it does for some inputs. Does it have value to my friend. Obviously! He can run it from the command line, and he can pass a file as an input. He will always get number “5” as a result of counting, though. That’s a bummer, but it’s an alpha version. He doesn’t expect it to work perfectly.</p><p>However, it works, it is backed by tests, and it is properly packaged.</p><p>What I just did is a top-down approach to design. First of all, I created something that provides value to my customer. I made sure it also satisfies my technical objectives, like proper unit test coverage and build automation. But the most important goal for me was to make sure my friend received something … and paid me.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Don't Repeat Yourself in Maven POMs; Use Jcabi-Parent </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/02/05/jcabi-parent-maven-pom.html>12 Best</li> <li /2015/02/05/jcabi-parent-maven-pom.html>All 292</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Webinars</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Talks</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Books</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Papers</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Pets</li> <li /2015/02/05/jcabi-parent-maven-pom.html class=”highlighted”>Trainings</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Award</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Testimonials</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Shift-M</li> <li /2015/02/05/jcabi-parent-maven-pom.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/02/05/jcabi-parent-maven-pom.html</p><h1 itemprop="name headline mainEntityOfPage">Don’t Repeat Yourself in Maven POMs; Use Jcabi-Parent</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable">
pom.xml, an XML file that can get very long. I’ve seen POM files of 3,000-plus lines. Taking into account 1) recent DSL buzz and 2) fear of XML, it’s only logical that many people don’t like Maven because of itspom.xmlverbosity.</p><p>But even if you’re an XML fan who enjoys its strictness and elegance (like myself), you won’t like the necessity to repeat yourself inpom.xmlfor every project. If you’re working on multiple projects, code duplication will be enormous. An average Java web app uses a few dozen standard Maven plugins and almost the same number of pretty common dependencies, like JUnit, Apache Commons, Log4J, Mockito, etc. All of them have their versions and configurations, which have to be specified if you want to keep the project stable and avoid Maven warnings. Thus, once a new version of a plugin is released, you have to go through allpom.xmlfiles in the projects you’re working on and update it there. You obviously understand what code duplication means. It’s a disaster. However, there is a solution.</p><p>jcabi-parent is a very simple Maven dependency with nothing inside it except a largepom.xmlwith multiple pre-configured dependencies, profiles, and plugins. All you need to do in order to reuse them all in your project is definecom.jcabi:parentas your parent POM:</p><pre> <p>That’s all you need. Now you can remove most of your custom configurations from<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.jcabi</groupId> <artifactId>parent</artifactId> <!-- check the latest version at http://parent.jcabi.com --> <version>0.32.1</version> </parent> [...] </project></pre>pom.xmland rely on defaults provided by jcabi-parent. Itspom.xmlis rather large and properly configured. Multiple projects depend on it, so you can be confident that you’re using the best possible configuration of all standard plugins.</p><p>Here are a few examples ofpom.xmlfrom projects that are using jcabi-parent (you can see how compact they are): Xembly ReXSL jcabi-http Qulice</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div >pom.xml, an XML file that can get very long. I’ve seen POM files of 3,000-plus lines. Taking into account 1) recent DSL buzz and 2) fear of XML, it’s only logical that many people don’t like Maven because of itspom.xmlverbosity.</p><p>But even if you’re an XML fan who enjoys its strictness and elegance (like myself), you won’t like the necessity to repeat yourself inpom.xmlfor every project. If you’re working on multiple projects, code duplication will be enormous. An average Java web app uses a few dozen standard Maven plugins and almost the same number of pretty common dependencies, like JUnit, Apache Commons, Log4J, Mockito, etc. All of them have their versions and configurations, which have to be specified if you want to keep the project stable and avoid Maven warnings. Thus, once a new version of a plugin is released, you have to go through allpom.xmlfiles in the projects you’re working on and update it there. You obviously understand what code duplication means. It’s a disaster. However, there is a solution.</p><p>jcabi-parent is a very simple Maven dependency with nothing inside it except a largepom.xmlwith multiple pre-configured dependencies, profiles, and plugins. All you need to do in order to reuse them all in your project is definecom.jcabi:parentas your parent POM:</p><pre> <p>That’s all you need. Now you can remove most of your custom configurations from<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.jcabi</groupId> <artifactId>parent</artifactId> <!-- check the latest version at http://parent.jcabi.com --> <version>0.32.1</version> </parent> [...] </project></pre>pom.xmland rely on defaults provided by jcabi-parent. Itspom.xmlis rather large and properly configured. Multiple projects depend on it, so you can be confident that you’re using the best possible configuration of all standard plugins.</p><p>Here are a few examples ofpom.xmlfrom projects that are using jcabi-parent (you can see how compact they are): Xembly ReXSL jcabi-http Qulice</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> XSL Transformation in Java: An Easy Way </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/02/02/xsl-transformations-in-java.html>12 Best</li> <li /2015/02/02/xsl-transformations-in-java.html>All 292</li> <li /2015/02/02/xsl-transformations-in-java.html>Webinars</li> <li /2015/02/02/xsl-transformations-in-java.html>Talks</li> <li /2015/02/02/xsl-transformations-in-java.html>Books</li> <li /2015/02/02/xsl-transformations-in-java.html>Papers</li> <li /2015/02/02/xsl-transformations-in-java.html>Pets</li> <li /2015/02/02/xsl-transformations-in-java.html class=”highlighted”>Trainings</li> <li /2015/02/02/xsl-transformations-in-java.html>Award</li> <li /2015/02/02/xsl-transformations-in-java.html>Testimonials</li> <li /2015/02/02/xsl-transformations-in-java.html>Shift-M</li> <li /2015/02/02/xsl-transformations-in-java.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/02/02/xsl-transformations-in-java.html</p><h1 itemprop="name headline mainEntityOfPage">XSL Transformation in Java: An Easy Way</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><pre> <p>Once a user posts+----+---------------+--------------------------------------+ | id | name | xml | +----+---------------+--------------------------------------+ | 12 | jcabi-xml#54 | <?xml version='1.0'?> | | | | <talk public="true"> | | | | <request id="e5f4b3">...</request> | | | | </talk> | +----+---------------+--------------------------------------+ | 13 | jcabi-email#2 | <?xml version='1.0'?> | | | | <talk public="true"> | | | | <daemon id="f787fe">...</daemon> | | | | </talk> | +----+---------------+--------------------------------------+</pre>@rultor statusinto a GitHub ticket, Rultor has to answer with a full status report about the current talk. In order to create such a text answer (a regular user would not appreciate an XML response), we have to fetch thatxmlcolumn from the necessary DynamoDB record and convert it to plain English text.</p><p>Here is how we’re doing that with the help of jcabi-xml and its class,XSLDocument.</p><pre> <p>That’s it. Now let’s see what’s there in thatfinal String xml = // comes from DynamoDB final XSL xsl = new XSLDocument( this.getClass().getResourceAsStream("status.xsl") ); final String text = xsl.applyTo(xml);</pre>status.xslfile (this is just a skeleton of it; the full version is here):</p><pre> <p>It is good practice to create XSL documents only once per application run. We have a static utility method<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"> <xsl:output method="text"/> <xsl:template match="/talk"> <xsl:text>Hi, here is your status report:</xsl:text> ... </xsl:template> <xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:template> </xsl:stylesheet></pre>XSLDocument.make()for this:</p><pre> <p>Pay attention to the fact we’re using XSLT 2.0. Built-in Java implementation of XSLT doesn’t support version 2.0, and in order to make it work, we’re using these two Maven Saxon dependencies:</p>final class Foo { private static final XSL STYLESHEET = XSLDocument.make( Foo.class.getResourceAsStream("stylesheet.xsl") ); public XML style(final XML xml) { return Foo.STYLESHEET.transform(xml); } }</pre><pre> <p>All you need to do to start using<dependency> <groupId>net.sourceforge.saxon</groupId> <artifactId>saxon</artifactId> <version>9.1.0.8</version> <scope>runtime</scope> </dependency> <dependency> <groupId>net.sourceforge.saxon</groupId> <artifactId>saxon</artifactId> <version>9.1.0.8</version> <classifier>xpath</classifier> <scope>runtime</scope> </dependency></pre>jcabi-xmlfor XSL transformations is add this dependency to yourpom.xml:</p><pre> <p>If you have any problems or suggestions, don’t hesitate to submit an issue to the GitHub issue tracker.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><dependency> <groupId>com.jcabi</groupId> <artifactId>jcabi-xml</artifactId> </dependency></pre><pre> <p>Once a user posts+----+---------------+--------------------------------------+ | id | name | xml | +----+---------------+--------------------------------------+ | 12 | jcabi-xml#54 | <?xml version='1.0'?> | | | | <talk public="true"> | | | | <request id="e5f4b3">...</request> | | | | </talk> | +----+---------------+--------------------------------------+ | 13 | jcabi-email#2 | <?xml version='1.0'?> | | | | <talk public="true"> | | | | <daemon id="f787fe">...</daemon> | | | | </talk> | +----+---------------+--------------------------------------+</pre>@rultor statusinto a GitHub ticket, Rultor has to answer with a full status report about the current talk. In order to create such a text answer (a regular user would not appreciate an XML response), we have to fetch thatxmlcolumn from the necessary DynamoDB record and convert it to plain English text.</p><p>Here is how we’re doing that with the help of jcabi-xml and its class,XSLDocument.</p><pre> <p>That’s it. Now let’s see what’s there in thatfinal String xml = // comes from DynamoDB final XSL xsl = new XSLDocument( this.getClass().getResourceAsStream("status.xsl") ); final String text = xsl.applyTo(xml);</pre>status.xslfile (this is just a skeleton of it; the full version is here):</p><pre> <p>It is good practice to create XSL documents only once per application run. We have a static utility method<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"> <xsl:output method="text"/> <xsl:template match="/talk"> <xsl:text>Hi, here is your status report:</xsl:text> ... </xsl:template> <xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:template> </xsl:stylesheet></pre>XSLDocument.make()for this:</p><pre> <p>Pay attention to the fact we’re using XSLT 2.0. Built-in Java implementation of XSLT doesn’t support version 2.0, and in order to make it work, we’re using these two Maven Saxon dependencies:</p>final class Foo { private static final XSL STYLESHEET = XSLDocument.make( Foo.class.getResourceAsStream("stylesheet.xsl") ); public XML style(final XML xml) { return Foo.STYLESHEET.transform(xml); } }</pre><pre> <p>All you need to do to start using<dependency> <groupId>net.sourceforge.saxon</groupId> <artifactId>saxon</artifactId> <version>9.1.0.8</version> <scope>runtime</scope> </dependency> <dependency> <groupId>net.sourceforge.saxon</groupId> <artifactId>saxon</artifactId> <version>9.1.0.8</version> <classifier>xpath</classifier> <scope>runtime</scope> </dependency></pre>jcabi-xmlfor XSL transformations is add this dependency to yourpom.xml:</p><pre> <p>If you have any problems or suggestions, don’t hesitate to submit an issue to the GitHub issue tracker.</p></div></article></div><div class="wrapper"><dependency> <groupId>com.jcabi</groupId> <artifactId>jcabi-xml</artifactId> </dependency></pre></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Making Your Boss Happy Is a False Objective </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/01/26/happy-boss-false-objective.html>12 Best</li> <li /2015/01/26/happy-boss-false-objective.html>All 292</li> <li /2015/01/26/happy-boss-false-objective.html>Webinars</li> <li /2015/01/26/happy-boss-false-objective.html>Talks</li> <li /2015/01/26/happy-boss-false-objective.html>Books</li> <li /2015/01/26/happy-boss-false-objective.html>Papers</li> <li /2015/01/26/happy-boss-false-objective.html>Pets</li> <li /2015/01/26/happy-boss-false-objective.html class=”highlighted”>Trainings</li> <li /2015/01/26/happy-boss-false-objective.html>Award</li> <li /2015/01/26/happy-boss-false-objective.html>Testimonials</li> <li /2015/01/26/happy-boss-false-objective.html>Shift-M</li> <li /2015/01/26/happy-boss-false-objective.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/01/26/happy-boss-false-objective.html</p><h1 itemprop="name headline mainEntityOfPage">Making Your Boss Happy Is a False Objective</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>We all have bosses. We also have customers who pay us for running their software projects. They are my bosses for the time of the contract. I’m also acting as a boss for developers who are working for Zerocracy. It is obvious that a good employee/contractor is one who makes his boss/customer happy. But only a bad employee works toward this goal. Trying to make your boss happy is a false target that, if pursued, ruins the project. A professional employee works for the project, not for the boss.</p>
<figcaption id="a14f03e8">The Million Dollar Hotel (2000) by Wim Wenders</figcaption></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> If. Then. Throw. Else. WTF? </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/01/21/if-then-throw-else.html>12 Best</li> <li /2015/01/21/if-then-throw-else.html>All 292</li> <li /2015/01/21/if-then-throw-else.html>Webinars</li> <li /2015/01/21/if-then-throw-else.html>Talks</li> <li /2015/01/21/if-then-throw-else.html>Books</li> <li /2015/01/21/if-then-throw-else.html>Papers</li> <li /2015/01/21/if-then-throw-else.html>Pets</li> <li /2015/01/21/if-then-throw-else.html class=”highlighted”>Trainings</li> <li /2015/01/21/if-then-throw-else.html>Award</li> <li /2015/01/21/if-then-throw-else.html>Testimonials</li> <li /2015/01/21/if-then-throw-else.html>Shift-M</li> <li /2015/01/21/if-then-throw-else.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/01/21/if-then-throw-else.html</p><h1 itemprop="name headline mainEntityOfPage">If. Then. Throw. Else. WTF?</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>This is the code I could never understand:</p><pre> <p>I have been trying to find a proper metaphor to explain its incorrectness. Today I finally found it.</p><p>If-then-else is a forking mechanism of procedural programming. The CPU either goes to the left and then does something or goes to the right and does something else. Imagine yourself driving a car and seeing this sign:</p>if (x < 0) { throw new Exception("X can't be negative"); } else { System.out.println("X is positive or zero"); }</pre>
<pre> <p>Now, try to imagine this sign:</p>if (x < 0) { System.out.println("X is negative"); } else { System.out.println("X is positive or zero"); }</pre>
<pre> <p>The same is true for loops. This is wrong:</p>if (x < 0) { throw new Exception("X can't be negative"); } System.out.println("X is positive or zero");</pre><pre> <p>While this is right:</p>for (int x : numbers) { if (x < 0) { continue; } else { System.out.println("found positive number"); } }</pre><pre> <p>There is no road after the dead end! If you draw it, your code looks like this very funny snippet I found a few years ago reviewing sources written by some very well-paid developer in one very serious company:</p>for (int x : numbers) { if (x < 0) { continue; } System.out.println("found positive number"); }</pre><pre> <p>Don’t do this.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>This is the code I could never understand:</p>if (x < 0) { throw new Exception("X is negative"); System.exit(1); }</pre><pre> <p>I have been trying to find a proper metaphor to explain its incorrectness. Today I finally found it.</p><p>If-then-else is a forking mechanism of procedural programming. The CPU either goes to the left and then does something or goes to the right and does something else. Imagine yourself driving a car and seeing this sign:</p>if (x < 0) { throw new Exception("X can't be negative"); } else { System.out.println("X is positive or zero"); }</pre><pre> <p>Now, try to imagine this sign:</p>if (x < 0) { System.out.println("X is negative"); } else { System.out.println("X is positive or zero"); }</pre><pre> <p>The same is true for loops. This is wrong:</p>if (x < 0) { throw new Exception("X can't be negative"); } System.out.println("X is positive or zero");</pre><pre> <p>While this is right:</p>for (int x : numbers) { if (x < 0) { continue; } else { System.out.println("found positive number"); } }</pre><pre> <p>There is no road after the dead end! If you draw it, your code looks like this very funny snippet I found a few years ago reviewing sources written by some very well-paid developer in one very serious company:</p>for (int x : numbers) { if (x < 0) { continue; } System.out.println("found positive number"); }</pre><pre> <p>Don’t do this.</p></div></article></div><div class="wrapper">if (x < 0) { throw new Exception("X is negative"); System.exit(1); }</pre></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> How to Cut Corners and Stay Cool </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/01/15/how-to-cut-corners.html>12 Best</li> <li /2015/01/15/how-to-cut-corners.html>All 292</li> <li /2015/01/15/how-to-cut-corners.html>Webinars</li> <li /2015/01/15/how-to-cut-corners.html>Talks</li> <li /2015/01/15/how-to-cut-corners.html>Books</li> <li /2015/01/15/how-to-cut-corners.html>Papers</li> <li /2015/01/15/how-to-cut-corners.html>Pets</li> <li /2015/01/15/how-to-cut-corners.html class=”highlighted”>Trainings</li> <li /2015/01/15/how-to-cut-corners.html>Award</li> <li /2015/01/15/how-to-cut-corners.html>Testimonials</li> <li /2015/01/15/how-to-cut-corners.html>Shift-M</li> <li /2015/01/15/how-to-cut-corners.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/01/15/how-to-cut-corners.html</p><h1 itemprop="name headline mainEntityOfPage">How to Cut Corners and Stay Cool</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="unprintable subline"> <li>Translated:</li> <li>Spanish</li> <li>add yours!</li></ul><p class="unprintable"><p>You have a task assigned to you, and you don’t like it. You are simply not in the mood. You don’t know how to fix that damn bug. You have no idea how that bloody module was designed, and you don’t know how it works. But you have to fix the issue, which was reported by someone who has no clue how this software works. You get frustrated and blame that stupid project manager and programmers who were fired two years ago. You spend hours just to find out how the code works. Then even more hours trying to fix it. In the end, you miss the deadline and everybody blames you. Been there, done that?</p>
<figcaption id="34ee5620">Regarding Henry (1991) by Mike Nichols</figcaption>
<div class="play"></div></div><div>Blame the Project; 16 April 2016.</div></aside><p>Here is a list of options you have, in order of preference. I would recommend you start with the first one on the list and proceed down when you have to.</p><h2 id="create-dependencies-blame-them-and-wait">Create Dependencies, Blame Them, and Wait</h2><p>This is the first and most preferable option. If you can’t figure out how to fix an issue or how to implement a new feature, it’s a fault of the project, not you. Even if you can’t figure it out because you don’t know anything about Ruby and they hired you to fix bugs in a Ruby on Rails code base—it’s their fault. Why did they hire you when you know nothing about Ruby?</p><p>So be positive; don’t blame yourself. If you don’t know how this damn code works, it’s a fault of the code, not you. Good code is easy to understand and maintain.</p>
@Ignoreannotation in JUnit 4) and commit your changes. Then add documentation to the unit test you just created, preferably in the form of a@todo. Explain there that you managed to reproduce the problem but didn’t have enough time to fix it. Or maybe you just don’t know how to fix it. Be honest and give all possible details.</p><p>I believe that catching a bug with a unit test is, in most cases, more than 80% of success. The rest is way more simple: just fix the code and make the test pass. Leave this job to someone else.</p><h2 id="prove-a-bugs-absence">Prove a Bug’s Absence</h2><p>Very often you simply can’t reproduce a bug. That’s not because the code is not testable and can’t be used in a unit test but because you can’t reproduce an error situation. You know that the code crashes in production, but you can’t crash it in a test. The error stack trace reported by the end user or your production logging system is not reproducible. It’s a very common situation. What do you do?</p>
<div class="play"></div></div><div>How to Cut Corners and Stay Cool (webinar #15); 1 June 2016.</div></aside><p>If, later on, the same problem occurs in production, a new bug will be reported. It will be linked to your ticket. Your experience will help someone investigate the bug further. Maybe that guy will also fail to catch the bug with a test and will also create a new, successful and “useless” test. And this may happen again and again. Eventually, this cumulative group experience will help the last guy catch the bug and fix it.</p><p>Thus, a new passing test is a good response to a bug that you can’t catch with a unit test.</p><h2 id="disable-the-feature">Disable the Feature</h2><p>Sometimes the unit test technique won’t work, mostly because a bug will be too important to be ignored. They won’t agree with you when you show them a unit test that proves the bug doesn’t exist. They will tell you that “when our users are trying to download a PDF, they get a blank page.” And they will also say they don’t really care about your bloody unit tests. All they care about is that PDF document that should be downloadable. So the trick with a unit test won’t work. What do you do?</p><aside class="quote">Production errors are not programmers’ mistakes, though delayed tickets are.</aside><p>It depends on many factors, and most of these factors are not technical. They are political, organizational, managerial, social, you name it. However, in most cases, I would recommend you disable that toxic feature, release a new version, and close the ticket.</p><p>You will take the problem off your shoulders and everybody will be pleased. Well, except that poor end user. But this is not your problem. This is the fault of management, which didn’t organize pre-production testing properly. Again, don’t take this blame on yourself. Your job is to keep the code clean and finish your tickets in a reasonable amount of time. Their job is to make sure that developers, testers, DevOps, marketers, product managers, and designers work together to deliver the product with an acceptable number of errors.</p><p>Production errors are not programmers’ mistakes, though delayed tickets are. If you keep a ticket in your hands for too long, you become an unmanageable unit of work. They simply can’t manage you anymore. You’re doing something, trying to fix the bug, saying “I’m trying, I’m trying …” How can they manage such a guy? Instead, you should deliver quickly, even if it comes at the cost of a temporarily disabled feature.</p><h2 id="say-no">Say No</h2><p>OK, let’s say none of the above works. The code is clean, the documentation is acceptable, but you can’t catch the bug, and they don’t accept a unit test from you as proof of the bug’s absence. They also don’t allow you to disable a feature, because it is critical to the user experience. What choices do you have? Just one.</p>
@Ignoreannotation in JUnit 4) and commit your changes. Then add documentation to the unit test you just created, preferably in the form of a@todo. Explain there that you managed to reproduce the problem but didn’t have enough time to fix it. Or maybe you just don’t know how to fix it. Be honest and give all possible details.</p><p>I believe that catching a bug with a unit test is, in most cases, more than 80% of success. The rest is way more simple: just fix the code and make the test pass. Leave this job to someone else.</p><h2 id="prove-a-bugs-absence">Prove a Bug’s Absence</h2><p>Very often you simply can’t reproduce a bug. That’s not because the code is not testable and can’t be used in a unit test but because you can’t reproduce an error situation. You know that the code crashes in production, but you can’t crash it in a test. The error stack trace reported by the end user or your production logging system is not reproducible. It’s a very common situation. What do you do?</p></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> A Compound Name Is a Code Smell </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/01/12/compound-name-is-code-smell.html>12 Best</li> <li /2015/01/12/compound-name-is-code-smell.html>All 292</li> <li /2015/01/12/compound-name-is-code-smell.html>Webinars</li> <li /2015/01/12/compound-name-is-code-smell.html>Talks</li> <li /2015/01/12/compound-name-is-code-smell.html>Books</li> <li /2015/01/12/compound-name-is-code-smell.html>Papers</li> <li /2015/01/12/compound-name-is-code-smell.html>Pets</li> <li /2015/01/12/compound-name-is-code-smell.html class=”highlighted”>Trainings</li> <li /2015/01/12/compound-name-is-code-smell.html>Award</li> <li /2015/01/12/compound-name-is-code-smell.html>Testimonials</li> <li /2015/01/12/compound-name-is-code-smell.html>Shift-M</li> <li /2015/01/12/compound-name-is-code-smell.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/01/12/compound-name-is-code-smell.html</p><h1 itemprop="name headline mainEntityOfPage">A Compound Name Is a Code Smell</h1><aside class='book'>Read more about this subject in Section 5.1
of my book</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="unprintable subline"> <li>Translated:</li> <li>Chinese</li> <li>add yours!</li></ul><p class="unprintable"><p>Do you name variables like textLength,table_name, orcurrent-user-email? All three are compound names that consist of more than one word. Even though they look more descriptive thanname,length, oremail, I would strongly recommend avoiding them. I believe a variable name that is more complex than a noun is a code smell. Why? Because we usually give a variable a compound name when its scope is so big and complex that a simple noun would sound ambiguous. And a big, complex scope is an obvious code smell.</p>
<figcaption id="6b72f309">The Meaning of Life (1983) by Terry Jones and Terry Gilliam</figcaption><pre> <p>The visible scope of variableclass CSV def initialize(csvFileName) @fileName = csvFileName end def readRecords() File.readLines(@fileName).map |csvLine| csvLine.split(',') end end end</pre>csvFileNameis methodinitialize(), which is a constructor of the classCSV. Why does it need a compound name that consists of three words? Isn’t it already clear that a single-argument constructor of classCSVexpects the name of a file with comma-separated values? I would rename it tofile.</p><p>Next, the scope of@fileNameis the entireCSVclass. Renaming a single variable in the class to just@filewon’t introduce any confusion. It’s still clear what file we’re dealing with. The same situation exists with thecsvLinevariable. It is clear that we’re dealing with CSV lines here. Thecsvprefix is just a redundancy. Here is how I would refactor the class:</p><pre> <p>Now it looks clear and concise.</p><p>If you can’t perform such a refactoring, it means your scope is too big and/or too complex. An ideal method should deal with up to five variables, and an ideal class should encapsulate up to five properties.</p><p>If we have five variables, can’t we find five nouns to name them?</p><p>Adam and Eve didn’t have second names. They were unique in Eden, as were many other characters in the Old Testament. Second and middle names were invented later in order to resolve ambiguity. To keep your methods and classes clean and solid, and to prevent ambiguity, try to give your variables and methods unique single-word names, just like Adam and Eve were named by you know who :)</p><p>PS. Also, redundant variables are evil as well.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Do you name variables likeclass CSV def initialize(file) @file = file end def records() File.readLines(@file).map |line| line.split(',') end end end</pre>textLength,table_name, orcurrent-user-email? All three are compound names that consist of more than one word. Even though they look more descriptive thanname,length, oremail, I would strongly recommend avoiding them. I believe a variable name that is more complex than a noun is a code smell. Why? Because we usually give a variable a compound name when its scope is so big and complex that a simple noun would sound ambiguous. And a big, complex scope is an obvious code smell.</p><pre> <p>The visible scope of variableclass CSV def initialize(csvFileName) @fileName = csvFileName end def readRecords() File.readLines(@fileName).map |csvLine| csvLine.split(',') end end end</pre>csvFileNameis methodinitialize(), which is a constructor of the classCSV. Why does it need a compound name that consists of three words? Isn’t it already clear that a single-argument constructor of classCSVexpects the name of a file with comma-separated values? I would rename it tofile.</p><p>Next, the scope of@fileNameis the entireCSVclass. Renaming a single variable in the class to just@filewon’t introduce any confusion. It’s still clear what file we’re dealing with. The same situation exists with thecsvLinevariable. It is clear that we’re dealing with CSV lines here. Thecsvprefix is just a redundancy. Here is how I would refactor the class:</p><pre> <p>Now it looks clear and concise.</p><p>If you can’t perform such a refactoring, it means your scope is too big and/or too complex. An ideal method should deal with up to five variables, and an ideal class should encapsulate up to five properties.</p><p>If we have five variables, can’t we find five nouns to name them?</p><p>Adam and Eve didn’t have second names. They were unique in Eden, as were many other characters in the Old Testament. Second and middle names were invented later in order to resolve ambiguity. To keep your methods and classes clean and solid, and to prevent ambiguity, try to give your variables and methods unique single-word names, just like Adam and Eve were named by you know who :)</p><p>PS. Also, redundant variables are evil as well.</p></div></article></div><div class="wrapper">class CSV def initialize(file) @file = file end def records() File.readLines(@file).map |line| line.split(',') end end end</pre></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> How to Be Honest and Keep a Customer </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>12 Best</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>All 292</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Webinars</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Talks</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Books</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Papers</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Pets</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html class=”highlighted”>Trainings</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Award</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Testimonials</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Shift-M</li> <li /2015/01/05/how-to-be-honest-and-keep-customer.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2015/01/05/how-to-be-honest-and-keep-customer.html</p><h1 itemprop="name headline mainEntityOfPage">How to Be Honest and Keep a Customer</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="subline"> <li>Discussed at:</li> <li>reddit</li></ul><p class="unprintable"><p>Most of our clients are rather surprised when we explain to them that they will have full access to the source code from the first day of the project. We let them see everything that is happening in the project, including the Git repository, bug reports, discussions between programmers, continuous integration fails, etc. They often tell me that other software development outsourcing teams keep this information in-house and deliver only final releases, rarely together with the source code.</p><p>I understand why other developers are trying to hide as much as possible. Giving a project sponsor full access to the development environment is not easy at all. Here is a summary of problems we’ve been having and our solutions. I hope they help you honestly show your clients all project internals and still keep them on board.</p>
<figcaption id="822a28fd">99 francs (2007) by Jan Kounen</figcaption>
<div class="play"></div></div><div>How to be Honest and Keep a Client?; 11 June 2017.</div></aside><p>Maybe our management is chaotic, and the client is trying to “organize” us by giving explicit instructions regarding the most important tasks. We’ve seen it before, and we are always trying to learn from this. As soon as we see that the client is trying to micro-manage us, we ask ourselves: “Is our process transparent enough? Do we give enough information to the client about milestones, risks, plans, costs, etc.?” In most cases, it’s our own fault, and we’re trying to learn and improve. If so, it’s important to react fast, before the client becomes too aggressive in his orders and instructions. It will be very difficult to escort him back to the normal process once he gets “micro-management” in his blood.</p><p>Maybe the client is not busy enough and has a lot of free time, which he is happy to spend by giving orders and distracting your team. I’ve seen this many times. A solution? Keep him busy. Turn him into a member of the team and assign him some tasks related to documentation and research. In my experience, most clients would be happy to do this work and help the project.</p><h2 id="he-is-asking-too-much">He Is Asking Too Much</h2><p>A technically-savvy client can turn the life of an architect into a nightmare by constantly asking him to explain every single technical decision made, from “Why PostgreSQL instead of MySQL?” to “Why doesn’t this method throw a checked exception?” Constantly answering such questions can turn a project into a school of programming. Even though he is paying for our time, that doesn’t mean we should teach him how to develop software, right? On the other hand, he is interested in knowing how his software is developed and how it works. It’s a fair request, isn’t it?</p><aside class="quote">He is interested in knowing how his software is developed and how it works. It’s a fair request, isn’t it?</aside><p>I believe there is a win-win solution to this problem. Here is how we manage it. First of all, we make all his requests formal. We ask a client to create a new ticket for each request, properly explaining what is not clear and how much detail is expected in the explanation.</p><p>Second, we look at such requests positively—they are good indicators of certain inconsistencies in the software. If it’s not clear for the client why PostgreSQL is used and not MySQL, it’s a fault of our architect. He didn’t document his decision and didn’t explain how it was made, what other options were considered, what selection criteria were applied, etc. Thus, a request from a client is a bug we get for free. So, we look at it positively.</p><p>Finally, we charge our clients for the answers given. Every question, submitted as a ticket, goes through the full flow and gets billed just as any other ticket. This approach prevents the client from asking for too much. He realizes that we’re ready to explain anything he wants, but he will pay for it.</p><h2 id="he-is-telling-too-much">He Is Telling Too Much</h2><p>This problem is even bigger than the previous one. Some clients believe they are savvy enough to argue with our architect and our programmers about how the software should be developed. They don’t just ask why PostgreSQL is used, they tell us that we should use MySQL, because “I know that it’s a great database; my friend is using it, and his business is growing!” Sometimes it gets even worse, when suggestions are directed at every class or even a method, like “You should use a Singleton pattern here!”</p><p>Our first choice is to agree and do what he wants. But it’s a road to nowhere. Once you do it, your project is ruined, and you should start thinking about a divorce with this client. Your entire team will quickly turn into a group of coding monkeys, micro-managed by someone with some cash. It’s a very wrong direction; don’t even think about going there.</p><p>The second choice is to tell the client to mind his own business and let us do ours. He hired us because we’re professional enough to develop the software according to his requirements. If he questions our capabilities, he is free to change the contractor. But until then, he has to trust our decisions. Will this work? I doubt it. It’s the same as giving him the finger. He will get offended, and you won’t get anything.</p><p>The solution here is to turn the client’s demands into project requirements. Most of them will be lost in the process, because they won’t be sane enough to form a good requirement. Others will be documented, estimated, and crossed-out by the client himself, because he will realize they are pointless or too expensive. Only a few of them will survive, since they will be reasonable enough. And they will help the project. So it is also a win-win solution.</p><aside class="quote">Never take a client’s demands directly to execution, but rather use them first to amend the requirements documentation.</aside><p>For example, he says that “you should use MySQL because it’s great.” You tell him that the project requirements document doesn’t limit you to choose whichever database you like. Should it? He says yes, of course! OK, let’s try to document such a requirement. How will it sound? How about, “We should only use great databases?” Sound correct? If so, then PostgreSQL satisfies this requirement. Problem solved; let us continue to do our work. He will have a hard time figuring out how to write a requirement in a way that disallows PostgreSQL but allows MySQL. It is simply not possible in most cases.</p><p>Sometimes, though, it will make sense; for example, “We should use a database server that understands our legacy data in MySQL format.” This is a perfectly sane requirement, and the only way to satisfy it is to use MySQL.</p><p>Thus, my recommendation is to never take a client’s demands directly to execution, but rather use them first to amend the requirements documentation. Even if you don’t have such documentation, create a simple one-page document. Agree with the client that you work against this document, and when anyone wants to change something, you first have to amend the document and then have your team ensure the software satisfies it. This kind of discipline will be accepted by any client and will protect you against sudden and distracting corrections.</p><h2 id="he-is-questioning-our-skills">He Is Questioning Our Skills</h2><p>When source code is open to the client, and he is technically capable of reading it, it is very possible that one day he will tell us that our code is crap and we have to learn how to program better. It has not happened in our projects for many years, but it has happened before, when we weren’t using static analysis as a mandatory step in our continuous integration pipeline.</p><p>Another funny possibility is when the client shows the source code to a “friend,” and he gives a “professional” opinion, which sounds like, “They don’t know what they are doing.” Once such an opinion hits your client’s ears, the project is at a significant risk of closure. It’ll be very difficult, almost impossible, to convince the client not to listen to the “friend” and continue to work with you. That’s why most outsourcers prefer to keep their sources private until the very end of the project, when the final invoice is paid.</p><aside class="quote">No matter how beautiful your architecture and your source code is, the “friend” will always be right.</aside><p>I think that an accidental appearance of a “friend” with a negative opinion is un-preventable. If it happens, it happens. You can’t avoid it. On the other hand, if you think your code is perfect and your team has only talented programmers writing beautiful software, this is not going to protect you either. An opinion coming from a “friend” won’t be objective; it will just be very personal, and that’s why it’s very credible. He is a friend of a client, and he doesn’t send him bills every week. Why would he lie? Of course, he is speaking from the heart! (I’m being sarcastic.) So, no matter how beautiful your architecture and your source code is, the “friend” will always be right.</p><p>In my opinion, the only way to prevent such a situation or minimize its consequences is to organize regular and systematic independent technical reviews. They will give confidence to the client that the team is not lying to him about the quality of the product and key technical decisions made internally.</p><hr /><p>To conclude, I strongly believe it is important to be honest and open with each client, no matter how difficult it is. Try to learn from every conflict with each client, and improve your management process and your principles of work. Hiding source code is not professional and makes you look bad in the eyes of your clients and the entire industry.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Most of our clients are rather surprised when we explain to them that they will have full access to the source code from the first day of the project. We let them see everything that is happening in the project, including the Git repository, bug reports, discussions between programmers, continuous integration fails, etc. They often tell me that other software development outsourcing teams keep this information in-house and deliver only final releases, rarely together with the source code.</p><p>I understand why other developers are trying to hide as much as possible. Giving a project sponsor full access to the development environment is not easy at all. Here is a summary of problems we’ve been having and our solutions. I hope they help you honestly show your clients all project internals and still keep them on board.</p></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> You Do Need Independent Technical Reviews! </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/12/18/independent-technical-reviews.html>12 Best</li> <li /2014/12/18/independent-technical-reviews.html>All 292</li> <li /2014/12/18/independent-technical-reviews.html>Webinars</li> <li /2014/12/18/independent-technical-reviews.html>Talks</li> <li /2014/12/18/independent-technical-reviews.html>Books</li> <li /2014/12/18/independent-technical-reviews.html>Papers</li> <li /2014/12/18/independent-technical-reviews.html>Pets</li> <li /2014/12/18/independent-technical-reviews.html class=”highlighted”>Trainings</li> <li /2014/12/18/independent-technical-reviews.html>Award</li> <li /2014/12/18/independent-technical-reviews.html>Testimonials</li> <li /2014/12/18/independent-technical-reviews.html>Shift-M</li> <li /2014/12/18/independent-technical-reviews.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/12/18/independent-technical-reviews.html</p><h1 itemprop="name headline mainEntityOfPage">You Do Need Independent Technical Reviews!</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Do you have a team of brilliant and enthusiastic programmers? Of course! You’ve carefully chosen them from a hundred candidates! Are they passionate about the product? Absolutely! They use cutting-edge technologies, never sleep, and hardly eat or drink anything except coffee! Do they believe in your business success? No doubts about it; they live and breathe all those features, releases, continuous delivery, user experience, etc. Are you sure they are developing the product correctly? Well, yes, you’re pretty sure; why wouldn’t they? …</p>
<figcaption id="4382e3b5">Arizona Dream (1992) by Emir Kusturica</figcaption>
.java,.rb,.php, etc.) Give him access to the database schema, continuous integration panel, build environment, issue tracking system, plans and schedules, work agendas, up-time reports, deployment pipeline, production logs, customer bug reports, statistics, etc. Everything that could help him understand how your system works, and more importantly, where and how it breaks, is very useful. Don’t limit the reviewer to the source code only—this is simply not enough! Let him see the big picture, and you will get a much more detailed and professional report.</p><p>Track How Inconsistencies Are Resolved. Once you get a report from the reviewer, make sure that the most important issues immediately get into your team’s backlog. Then, make sure they are addressed and closed. That doesn’t mean you should fix them all and listen to everything said by the reviewer. Definitely not! Your architect runs the show, not the reviewer. Your architect should decide what is right and what is wrong in the technical implementation of the product. But it’s important to make him resolve all concerns raised by the reviewer. Very often you will get answers like these from him: “We don’t care about it now,” “we won’t fix it until the next release,” or “he is wrong; we’re doing it better.” These answers are perfectly valid, but they have to be given (reviewers are people and they also make mistakes). The answers will help you, the founder, understand what your team is doing and how well they understand their business.</p><hr /><p>If you can offer more suggestions, based on your experience, please post them below in the comments, and I’ll add them to the list. I’m still thinking that I may have forgotten something important :)</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Do you have a team of brilliant and enthusiastic programmers? Of course! You’ve carefully chosen them from a hundred candidates! Are they passionate about the product? Absolutely! They use cutting-edge technologies, never sleep, and hardly eat or drink anything except coffee! Do they believe in your business success? No doubts about it; they live and breathe all those features, releases, continuous delivery, user experience, etc. Are you sure they are developing the product correctly? Well, yes, you’re pretty sure; why wouldn’t they? …</p>.java,.rb,.php, etc.) Give him access to the database schema, continuous integration panel, build environment, issue tracking system, plans and schedules, work agendas, up-time reports, deployment pipeline, production logs, customer bug reports, statistics, etc. Everything that could help him understand how your system works, and more importantly, where and how it breaks, is very useful. Don’t limit the reviewer to the source code only—this is simply not enough! Let him see the big picture, and you will get a much more detailed and professional report.</p><p>Track How Inconsistencies Are Resolved. Once you get a report from the reviewer, make sure that the most important issues immediately get into your team’s backlog. Then, make sure they are addressed and closed. That doesn’t mean you should fix them all and listen to everything said by the reviewer. Definitely not! Your architect runs the show, not the reviewer. Your architect should decide what is right and what is wrong in the technical implementation of the product. But it’s important to make him resolve all concerns raised by the reviewer. Very often you will get answers like these from him: “We don’t care about it now,” “we won’t fix it until the next release,” or “he is wrong; we’re doing it better.” These answers are perfectly valid, but they have to be given (reviewers are people and they also make mistakes). The answers will help you, the founder, understand what your team is doing and how well they understand their business.</p><hr /><p>If you can offer more suggestions, based on your experience, please post them below in the comments, and I’ll add them to the list. I’m still thinking that I may have forgotten something important :)</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> How Immutability Helps </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/11/07/how-immutability-helps.html>12 Best</li> <li /2014/11/07/how-immutability-helps.html>All 292</li> <li /2014/11/07/how-immutability-helps.html>Webinars</li> <li /2014/11/07/how-immutability-helps.html>Talks</li> <li /2014/11/07/how-immutability-helps.html>Books</li> <li /2014/11/07/how-immutability-helps.html>Papers</li> <li /2014/11/07/how-immutability-helps.html>Pets</li> <li /2014/11/07/how-immutability-helps.html class=”highlighted”>Trainings</li> <li /2014/11/07/how-immutability-helps.html>Award</li> <li /2014/11/07/how-immutability-helps.html>Testimonials</li> <li /2014/11/07/how-immutability-helps.html>Shift-M</li> <li /2014/11/07/how-immutability-helps.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/11/07/how-immutability-helps.html</p><h1 itemprop="name headline mainEntityOfPage">How Immutability Helps</h1><aside class='book'>Read more about this subject in Section 2.6
of my book</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="subline"> <li>Discussed at:</li> <li>reddit</li></ul><p class="unprintable"><p>In a few recent posts, including Getters/Setters. Evil. Period. Objects Should Be Immutable, and Dependency Injection Containers are Code Polluters, I universally labeled all mutable objects with “setters” (object methods starting with set) evil. My argumentation was based mostly on metaphors and abstract examples. Apparently, this wasn’t convincing enough for many of you—I received a few requests asking to provide more specific and practical examples.</p><p>Thus, in order to illustrate my strongly negative attitude to “mutability via setters,” I took an existing commons-email Java library from Apache and re-designed it my way, without setters and with “object thinking” in mind. I released my library as part of the jcabi family—jcabi-email. Let’s see what benefits we get from a “pure” object-oriented and immutable approach, without getters.</p><p>Here is how your code will look, if you send an email using commons-email:</p><pre> <p>Here is how you do the same with jcabi-email:</p>Email email = new SimpleEmail(); email.setHostName("smtp.googlemail.com"); email.setSmtpPort(465); email.setAuthenticator(new DefaultAuthenticator("user", "pwd")); email.setFrom("yegor256@gmail.com", "Yegor Bugayenko"); email.addTo("dude@jcabi.com"); email.setSubject("how are you?"); email.setMsg("Dude, how are you?"); email.send();</pre><pre> <p>I think the difference is obvious.</p><p>In the first example, you’re dealing with a monster class that can do everything for you, including sending your MIME message via SMTP, creating the message, configuring its parameters, adding MIME parts to it, etc. ThePostman postman = new Postman.Default( new SMTP("smtp.googlemail.com", 465, "user", "pwd") ); Envelope envelope = new Envelope.MIME( new Array<Stamp>( new StSender("Yegor Bugayenko <yegor256@gmail.com>"), new StRecipient("dude@jcabi.com"), new StSubject("how are you?") ), new Array<Enclosure>( new EnPlain("Dude, how are you?") ) ); postman.send(envelope);</pre>Emailclass from commons-email is really a huge class—33 private properties, over a hundred methods, about two thousands lines of code. First, you configure the class through a bunch of setters and then you ask it tosend()an email for you.</p><aside class="youtube"> <div class="box">
<div class="play"></div></div><div>Immutable Objects vs. Common Sense (webinar #2); 6 May 2015.</div></aside><p>In the second example, we have seven objects instantiated via seven newcalls.Postmanis responsible for packaging a MIME message;SMTPis responsible for sending it via SMTP; stamps (StSender,StRecipient, andStSubject) are responsible for configuring the MIME message before delivery; enclosureEnPlainis responsible for creating a MIME part for the message we’re going to send. We construct these seven objects, encapsulating one into another, and then we ask the postman tosend()the envelope for us.</p><h2 id="whats-wrong-with-a-mutable-email">What’s Wrong With a Mutable Email?</h2><p>From a user perspective, there is almost nothing wrong.Emailis a powerful class with multiple controls—just hit the right one and the job gets done. However, from a developer perspectiveEmailclass is a nightmare. Mostly because the class is very big and difficult to maintain.</p><p>Because the class is so big, every time you want to extend it by introducing a new method, you’re facing the fact that you’re making the class even worse—longer, less cohesive, less readable, less maintainable, etc. You have a feeling that you’re digging into something dirty and that there is no hope to make it cleaner, ever. I’m sure, you’re familiar with this feeling—most legacy applications look that way. They have huge multi-line “classes” (in reality, COBOL programs written in Java) that were inherited from a few generations of programmers before you. When you start, you’re full of energy, but after a few minutes of scrolling such a “class” you say—“screw it, it’s almost Saturday.”</p><aside class="youtube"> <div class="box">
<div class="play"></div></div><div>How Immutability Helps in OOP (in Russian with English subtitles); 21 May 2016.</div></aside><p>Because the class is so big, there is no data hiding or encapsulation any more—33 variables are accessible by over 100 methods. What is hidden? This Email.javafile in reality is a big, procedural 2000-line script, called a “class” by mistake. Nothing is hidden, once you cross the border of the class by calling one of its methods. After that, you have full access to all the data you may need. Why is this bad? Well, why do we need encapsulation in the first place? In order to protect one programmer from another, aka defensive programming. While I’m busy changing the subject of the MIME message, I want to be sure that I’m not interfered with by some other method’s activity, that is changing a sender and touching my subject by mistake. Encapsulation helps us narrow down the scope of the problem, while thisEmailclass is doing exactly the opposite.</p><p>Because the class is so big, its unit testing is even more complicated than the class itself. Why? Because of multiple inter-dependencies between its methods and properties. In order to testsetCharset()you have to prepare the entire object by calling a few other methods, then you have to callsend()to make sure the message being sent actually uses the encoding you specified. Thus, in order to test a one-line methodsetCharset()you run the entire integration testing scenario of sending a full MIME message through SMTP. Obviously, if something gets changed in one of the methods, almost every test method will be affected. In other words, tests are very fragile, unreliable and over-complicated.</p><p>I can go on and on with this “because the class is so big,” but I think it is obvious that a small, cohesive class is always better than a big one. It is obvious to me, to you, and to any object-oriented programmer. But why is it not so obvious to the developers of Apache Commons Email? I don’t think they are stupid or un-educated. What is it then?</p><h2 id="how-and-why-did-it-happen">How and Why Did It Happen?</h2><p>This is how it always happens. You start to design a class as something cohesive, solid, and small. Your intentions are very positive. Very soon you realize that there is something else that this class has to do. Then, something else. Then, even more.</p><p>The best way to make your class more and more powerful is by adding setters that inject configuration parameters into the class so that it can process them inside, isn’t it?</p><aside class="youtube"> <div class="box">
<div class="play"></div></div><div>How Much Immutability Is Enough?; 19 May 2016.</div></aside><p>This is the root cause of the problem! The root cause is our ability to insert data into mutable objects via configuration methods, also known as “setters.” When an object is mutable and allows us to add setters whenever we want, we will do it without limits.</p><p>Let me put it this way—mutable classes tend to grow in size and lose cohesiveness.</p><p>If commons-email authors made this Emailclass immutable in the beginning, they wouldn’t have been able to add so many methods into it and encapsulate so many properties. They wouldn’t be able to turn it into a monster. Why? Because an immutable object only accepts a state through a constructor. Can you imagine a 33-argument constructor? Of course, not.</p><p>When you make your class immutable in the first place, you are forced to keep it cohesive, small, solid and robust. Because you can’t encapsulate too much and you can’t modify what’s encapsulated. Just two or three arguments of a constructor and you’re done.</p><h2 id="how-did-i-design-an-immutable-email">How Did I Design An Immutable Email?</h2>Postman. Well, it is an interface, since I never make interface-less classes. So,Postmanis… a post man. He is delivering messages to other people. First, I created a default version of it (I omit the ctor, for the sake of brevity):</p><pre> <p>Good start, it works. What now? Well, theimport javax.mail.Message; @Immutable class Postman.Default implements Postman { private final String host; private final int port; private final String user; private final String password; @Override void send(Message msg) { // create SMTP session // create transport // transport.connect(this.host, this.port, etc.) // transport.send(msg) // transport.close(); } }</pre>Messageis difficult to construct. It is a complex class from JDK that requires some manipulations before it can become a nice HTML email. So I created an envelope, which will build this complex object for me (pay attention, bothPostmanandEnvelopeare immutable and annotated with @Immutable from jcabi-aspects):</p><pre> <p>I also refactor the@Immutable interface Envelope { Message unwrap(); }</pre>Postmanto accept an envelope, not a message:</p><pre> <p>So far, so good. Now let’s try to create a simple implementation of@Immutable interface Postman { void send(Envelope env); }</pre>Envelope:</p><pre> <p>It works, but it does nothing useful yet. It only creates an absolutely empty MIME message and returns it. How about adding a subject to it and both@Immutable class MIME implements Envelope { @Override public Message unwrap() { return new MimeMessage( Session.getDefaultInstance(new Properties()) ); } }</pre>To:andFrom:addresses (pay attention,MIMEclass is also immutable):</p><pre> <p>Looks correct and it works. But it is still too primitive. How about@Immutable class Envelope.MIME implements Envelope { private final String subject; private final String from; private final Array<String> to; public MIME(String subj, String sender, Iterable<String> rcpts) { this.subject = subj; this.from = sender; this.to = new Array<String>(rcpts); } @Override public Message unwrap() { Message msg = new MimeMessage( Session.getDefaultInstance(new Properties()) ); msg.setSubject(this.subject); msg.setFrom(new InternetAddress(this.from)); for (String email : this.to) { msg.setRecipient( Message.RecipientType.TO, new InternetAddress(email) ); } return msg; } }</pre>CC:andBCC:? What about email text? How about PDF enclosures? What if I want to specify the encoding of the message? What aboutReply-To?</p><p>Can I add all these parameters to the constructor? Remember, the class is immutable and I can’t introduce thesetReplyTo()method. I have to pass thereplyToargument into its constructor. It’s impossible, because the constructor will have too many arguments, and nobody will be able to use it.</p><p>So, what do I do?</p><p>Well, I started to think: how can we break the concept of an “envelope” into smaller concepts—and this what I invented. Like a real-life envelope, myMIMEobject will have stamps. Stamps will be responsible for configuring an objectMessage(again,Stampis immutable, as well as all its implementers):</p><pre> <p>Now, I can simplify my@Immutable interface Stamp { void attach(Message message); }</pre>MIMEclass to the following:</p><pre> <p>Now, I will create stamps for the subject, for@Immutable class Envelope.MIME implements Envelope { private final Array<Stamp> stamps; public MIME(Iterable<Stamp> stmps) { this.stamps = new Array<Stamp>(stmps); } @Override public Message unwrap() { Message msg = new MimeMessage( Session.getDefaultInstance(new Properties()) ); for (Stamp stamp : this.stamps) { stamp.attach(msg); } return msg; } }</pre>To:, forFrom:, forCC:, forBCC:, etc. As many stamps as I like. The classMIMEwill stay the same—small, cohesive, readable, solid, etc.</p><p>What is important here is why I made the decision to refactor while the class was relatively small. Indeed, I started to worry about these stamp classes when myMIMEclass was just 25 lines in size.</p><p>That is exactly the point of this article—immutability forces you to design small and cohesive objects.</p><p>Without immutability, I would have gone the same direction as commons-email. MyMIMEclass would grow in size and sooner or later would become as big asEmailfrom commons-email. The only thing that stopped me was the necessity to refactor it, because I wasn’t able to pass all arguments through a constructor.</p><p>Without immutability, I wouldn’t have had that motivator and I would have done what Apache developers did with commons-email—bloat the class and turn it into an unmaintainable monster.</p><p>That’s jcabi-email. I hope this example was illustrative enough and that you will start writing cleaner code with immutable objects.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>In a few recent posts, including Getters/Setters. Evil. Period. Objects Should Be Immutable, and Dependency Injection Containers are Code Polluters, I universally labeled all mutable objects with “setters” (object methods starting withset) evil. My argumentation was based mostly on metaphors and abstract examples. Apparently, this wasn’t convincing enough for many of you—I received a few requests asking to provide more specific and practical examples.</p><p>Thus, in order to illustrate my strongly negative attitude to “mutability via setters,” I took an existing commons-email Java library from Apache and re-designed it my way, without setters and with “object thinking” in mind. I released my library as part of the jcabi family—jcabi-email. Let’s see what benefits we get from a “pure” object-oriented and immutable approach, without getters.</p><p>Here is how your code will look, if you send an email using commons-email:</p><pre> <p>Here is how you do the same with jcabi-email:</p>Email email = new SimpleEmail(); email.setHostName("smtp.googlemail.com"); email.setSmtpPort(465); email.setAuthenticator(new DefaultAuthenticator("user", "pwd")); email.setFrom("yegor256@gmail.com", "Yegor Bugayenko"); email.addTo("dude@jcabi.com"); email.setSubject("how are you?"); email.setMsg("Dude, how are you?"); email.send();</pre><pre> <p>I think the difference is obvious.</p><p>In the first example, you’re dealing with a monster class that can do everything for you, including sending your MIME message via SMTP, creating the message, configuring its parameters, adding MIME parts to it, etc. ThePostman postman = new Postman.Default( new SMTP("smtp.googlemail.com", 465, "user", "pwd") ); Envelope envelope = new Envelope.MIME( new Array<Stamp>( new StSender("Yegor Bugayenko <yegor256@gmail.com>"), new StRecipient("dude@jcabi.com"), new StSubject("how are you?") ), new Array<Enclosure>( new EnPlain("Dude, how are you?") ) ); postman.send(envelope);</pre>Emailclass from commons-email is really a huge class—33 private properties, over a hundred methods, about two thousands lines of code. First, you configure the class through a bunch of setters and then you ask it tosend()an email for you.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Immutable Objects vs. Common Sense (webinar #2); 6 May 2015.</div></aside><p>In the second example, we have seven objects instantiated via seven newcalls.Postmanis responsible for packaging a MIME message;SMTPis responsible for sending it via SMTP; stamps (StSender,StRecipient, andStSubject) are responsible for configuring the MIME message before delivery; enclosureEnPlainis responsible for creating a MIME part for the message we’re going to send. We construct these seven objects, encapsulating one into another, and then we ask the postman tosend()the envelope for us.</p><h2 id="whats-wrong-with-a-mutable-email">What’s Wrong With a Mutable Email?</h2><p>From a user perspective, there is almost nothing wrong.Emailis a powerful class with multiple controls—just hit the right one and the job gets done. However, from a developer perspectiveEmailclass is a nightmare. Mostly because the class is very big and difficult to maintain.</p><p>Because the class is so big, every time you want to extend it by introducing a new method, you’re facing the fact that you’re making the class even worse—longer, less cohesive, less readable, less maintainable, etc. You have a feeling that you’re digging into something dirty and that there is no hope to make it cleaner, ever. I’m sure, you’re familiar with this feeling—most legacy applications look that way. They have huge multi-line “classes” (in reality, COBOL programs written in Java) that were inherited from a few generations of programmers before you. When you start, you’re full of energy, but after a few minutes of scrolling such a “class” you say—“screw it, it’s almost Saturday.”</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>How Immutability Helps in OOP (in Russian with English subtitles); 21 May 2016.</div></aside><p>Because the class is so big, there is no data hiding or encapsulation any more—33 variables are accessible by over 100 methods. What is hidden? This Email.javafile in reality is a big, procedural 2000-line script, called a “class” by mistake. Nothing is hidden, once you cross the border of the class by calling one of its methods. After that, you have full access to all the data you may need. Why is this bad? Well, why do we need encapsulation in the first place? In order to protect one programmer from another, aka defensive programming. While I’m busy changing the subject of the MIME message, I want to be sure that I’m not interfered with by some other method’s activity, that is changing a sender and touching my subject by mistake. Encapsulation helps us narrow down the scope of the problem, while thisEmailclass is doing exactly the opposite.</p><p>Because the class is so big, its unit testing is even more complicated than the class itself. Why? Because of multiple inter-dependencies between its methods and properties. In order to testsetCharset()you have to prepare the entire object by calling a few other methods, then you have to callsend()to make sure the message being sent actually uses the encoding you specified. Thus, in order to test a one-line methodsetCharset()you run the entire integration testing scenario of sending a full MIME message through SMTP. Obviously, if something gets changed in one of the methods, almost every test method will be affected. In other words, tests are very fragile, unreliable and over-complicated.</p><p>I can go on and on with this “because the class is so big,” but I think it is obvious that a small, cohesive class is always better than a big one. It is obvious to me, to you, and to any object-oriented programmer. But why is it not so obvious to the developers of Apache Commons Email? I don’t think they are stupid or un-educated. What is it then?</p><h2 id="how-and-why-did-it-happen">How and Why Did It Happen?</h2><p>This is how it always happens. You start to design a class as something cohesive, solid, and small. Your intentions are very positive. Very soon you realize that there is something else that this class has to do. Then, something else. Then, even more.</p><p>The best way to make your class more and more powerful is by adding setters that inject configuration parameters into the class so that it can process them inside, isn’t it?</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>How Much Immutability Is Enough?; 19 May 2016.</div></aside><p>This is the root cause of the problem! The root cause is our ability to insert data into mutable objects via configuration methods, also known as “setters.” When an object is mutable and allows us to add setters whenever we want, we will do it without limits.</p><p>Let me put it this way—mutable classes tend to grow in size and lose cohesiveness.</p><p>If commons-email authors made this Emailclass immutable in the beginning, they wouldn’t have been able to add so many methods into it and encapsulate so many properties. They wouldn’t be able to turn it into a monster. Why? Because an immutable object only accepts a state through a constructor. Can you imagine a 33-argument constructor? Of course, not.</p><p>When you make your class immutable in the first place, you are forced to keep it cohesive, small, solid and robust. Because you can’t encapsulate too much and you can’t modify what’s encapsulated. Just two or three arguments of a constructor and you’re done.</p><h2 id="how-did-i-design-an-immutable-email">How Did I Design An Immutable Email?</h2>Postman. Well, it is an interface, since I never make interface-less classes. So,Postmanis… a post man. He is delivering messages to other people. First, I created a default version of it (I omit the ctor, for the sake of brevity):</p><pre> <p>Good start, it works. What now? Well, theimport javax.mail.Message; @Immutable class Postman.Default implements Postman { private final String host; private final int port; private final String user; private final String password; @Override void send(Message msg) { // create SMTP session // create transport // transport.connect(this.host, this.port, etc.) // transport.send(msg) // transport.close(); } }</pre>Messageis difficult to construct. It is a complex class from JDK that requires some manipulations before it can become a nice HTML email. So I created an envelope, which will build this complex object for me (pay attention, bothPostmanandEnvelopeare immutable and annotated with @Immutable from jcabi-aspects):</p><pre> <p>I also refactor the@Immutable interface Envelope { Message unwrap(); }</pre>Postmanto accept an envelope, not a message:</p><pre> <p>So far, so good. Now let’s try to create a simple implementation of@Immutable interface Postman { void send(Envelope env); }</pre>Envelope:</p><pre> <p>It works, but it does nothing useful yet. It only creates an absolutely empty MIME message and returns it. How about adding a subject to it and both@Immutable class MIME implements Envelope { @Override public Message unwrap() { return new MimeMessage( Session.getDefaultInstance(new Properties()) ); } }</pre>To:andFrom:addresses (pay attention,MIMEclass is also immutable):</p><pre> <p>Looks correct and it works. But it is still too primitive. How about@Immutable class Envelope.MIME implements Envelope { private final String subject; private final String from; private final Array<String> to; public MIME(String subj, String sender, Iterable<String> rcpts) { this.subject = subj; this.from = sender; this.to = new Array<String>(rcpts); } @Override public Message unwrap() { Message msg = new MimeMessage( Session.getDefaultInstance(new Properties()) ); msg.setSubject(this.subject); msg.setFrom(new InternetAddress(this.from)); for (String email : this.to) { msg.setRecipient( Message.RecipientType.TO, new InternetAddress(email) ); } return msg; } }</pre>CC:andBCC:? What about email text? How about PDF enclosures? What if I want to specify the encoding of the message? What aboutReply-To?</p><p>Can I add all these parameters to the constructor? Remember, the class is immutable and I can’t introduce thesetReplyTo()method. I have to pass thereplyToargument into its constructor. It’s impossible, because the constructor will have too many arguments, and nobody will be able to use it.</p><p>So, what do I do?</p><p>Well, I started to think: how can we break the concept of an “envelope” into smaller concepts—and this what I invented. Like a real-life envelope, myMIMEobject will have stamps. Stamps will be responsible for configuring an objectMessage(again,Stampis immutable, as well as all its implementers):</p><pre> <p>Now, I can simplify my@Immutable interface Stamp { void attach(Message message); }</pre>MIMEclass to the following:</p><pre> <p>Now, I will create stamps for the subject, for@Immutable class Envelope.MIME implements Envelope { private final Array<Stamp> stamps; public MIME(Iterable<Stamp> stmps) { this.stamps = new Array<Stamp>(stmps); } @Override public Message unwrap() { Message msg = new MimeMessage( Session.getDefaultInstance(new Properties()) ); for (Stamp stamp : this.stamps) { stamp.attach(msg); } return msg; } }</pre>To:, forFrom:, forCC:, forBCC:, etc. As many stamps as I like. The classMIMEwill stay the same—small, cohesive, readable, solid, etc.</p><p>What is important here is why I made the decision to refactor while the class was relatively small. Indeed, I started to worry about these stamp classes when myMIMEclass was just 25 lines in size.</p><p>That is exactly the point of this article—immutability forces you to design small and cohesive objects.</p><p>Without immutability, I would have gone the same direction as commons-email. MyMIMEclass would grow in size and sooner or later would become as big asEmailfrom commons-email. The only thing that stopped me was the necessity to refactor it, because I wasn’t able to pass all arguments through a constructor.</p><p>Without immutability, I wouldn’t have had that motivator and I would have done what Apache developers did with commons-email—bloat the class and turn it into an unmaintainable monster.</p><p>That’s jcabi-email. I hope this example was illustrative enough and that you will start writing cleaner code with immutable objects.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> What Does a Software Architect Do? </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/10/12/who-is-software-architect.html>12 Best</li> <li /2014/10/12/who-is-software-architect.html>All 292</li> <li /2014/10/12/who-is-software-architect.html>Webinars</li> <li /2014/10/12/who-is-software-architect.html>Talks</li> <li /2014/10/12/who-is-software-architect.html>Books</li> <li /2014/10/12/who-is-software-architect.html>Papers</li> <li /2014/10/12/who-is-software-architect.html>Pets</li> <li /2014/10/12/who-is-software-architect.html class=”highlighted”>Trainings</li> <li /2014/10/12/who-is-software-architect.html>Award</li> <li /2014/10/12/who-is-software-architect.html>Testimonials</li> <li /2014/10/12/who-is-software-architect.html>Shift-M</li> <li /2014/10/12/who-is-software-architect.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/10/12/who-is-software-architect.html</p><h1 itemprop="name headline mainEntityOfPage">What Does a Software Architect Do?</h1><aside class='book'>
Read more about this subject in Section 2
of my book</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="unprintable subline"> <li>Translated:</li> <li>Japanese</li> <li>add yours!</li></ul><p class="unprintable"><p>Do you have a software architect in your project? Do you need one? Well, most agile teams do not define such a role explicitly and work in a democratic mode. Every important technical decision is discussed with the entire team, and the most voted for solution wins. When such a team eventually decides to put a “software architect” badge on someone’s t-shirt, the most reputable programmer gets it.</p>
<figcaption id="f41988de">Jackie Brown (1997) by Quentin Tarantino</figcaption>
<div class="play"></div></div><div>Who Is a Software Architect?; 13 April 2015.</div></aside><p>Absolutely wrong!</p><p>Obviously, an architect is usually someone who has the most knowledge, skills, experience, and authority. Of course, an architect usually knows more than others and is able to communicate his knowledge with diplomacy and pedagogy when required. An architect is usually one of the smartest guys on the team.</p><aside class="quote">An architect is the one who takes the blame for the quality</aside><p>This is not, however, what makes him/her an architect.</p><p>And this is not what the team needs. My definition of a software architect is this:</p><p>An architect is the one who takes the blame for the quality.</p><aside class="youtube"> <div class="box"> 
<div class="play"></div></div><div>Hacker vs Designer Mentality; 13 April 2015.</div></aside><p>You can replace “blame” with accountability or responsibility. Although, I prefer to use “blame,” because it much better emphasizes the fact that every quality issue in the product under development is a personal fault of the architect. Of course, together with the blame he also takes all the credit from happy customers, when the quality is good.</p><p>This is what the team needs—someone personally responsible for the quality of the software being developed.</p><aside class="quote">The job of the PM is to make sure that every technical decision the architect makes is not doubted by anyone</aside><p>How this guy will delegate this responsibility to others is his job. Whether he will use his knowledge and skills, or quality control tools, or unit testing frameworks, or authority, or coaching, or corporal punishment—it’s his business. A project manager delegates quality control to the software architect, and it is up to the software architect how to delegate it further.</p><p>The role of a software architect is crucial for every project, even if there are just two coders working at the same desk. One of them has to be the architect.</p><p>An ideal architect has all the merits mentioned above. He listens to everybody and takes their opinions into account. He is a good coach and a teacher, with a lot of patience. He is an effective communicator and negotiator. He is a diplomat. And he is an expert in the technical domain.</p><p>But, even if he doesn’t have all these merits, his decision is always final.</p><p>And this is the job of the project manager, to make sure that every technical decision the architect makes is not doubted by anyone. This is what delegation is all about—responsibility should always come with power.</p><aside class="youtube"> <div class="box"> 
<div class="play"></div></div><div>Who is a Software Architect? (webinar #13); 13 April 2016.</div></aside><p>As a project manager, you should regularly evaluate the results of your architect. Remember, the quality of the product your team is working on is his personal (!) responsibility. Any problems you see are his problems. Don’t be afraid to blame him and punish him. But, always remember that in order to make your punishments productive you should give your architect full power in his actions. Let me reiterate: his decisions should be final.</p><p>If you, as a project manager, are not happy with the quality of the product and the architect doesn’t improve the situation, replace him. Downgrade him to a programmer and promote one of the programmers to an architect. But always remember that there can only be one architect in the team, and that his decisions are final.</p><p>That’s the only way of having a chance of building a perfect product.</p><blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Does your team have an official role of a Software Architect, who has enough authority to make technical decisions alone? #codeahead</p>— Yegor Bugayenko (@yegor256) May 13, 2018</blockquote> </p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Do you have a software architect in your project? Do you need one? Well, most agile teams do not define such a role explicitly and work in a democratic mode. Every important technical decision is discussed with the entire team, and the most voted for solution wins. When such a team eventually decides to put a “software architect” badge on someone’s t-shirt, the most reputable programmer gets it.</p></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Continuous Integration is Dead </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/10/08/continuous-integration-is-dead.html>12 Best</li> <li /2014/10/08/continuous-integration-is-dead.html>All 292</li> <li /2014/10/08/continuous-integration-is-dead.html>Webinars</li> <li /2014/10/08/continuous-integration-is-dead.html>Talks</li> <li /2014/10/08/continuous-integration-is-dead.html>Books</li> <li /2014/10/08/continuous-integration-is-dead.html>Papers</li> <li /2014/10/08/continuous-integration-is-dead.html>Pets</li> <li /2014/10/08/continuous-integration-is-dead.html class=”highlighted”>Trainings</li> <li /2014/10/08/continuous-integration-is-dead.html>Award</li> <li /2014/10/08/continuous-integration-is-dead.html>Testimonials</li> <li /2014/10/08/continuous-integration-is-dead.html>Shift-M</li> <li /2014/10/08/continuous-integration-is-dead.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/10/08/continuous-integration-is-dead.html</p><h1 itemprop="name headline mainEntityOfPage">Continuous Integration is Dead</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="subline"> <li>Discussed at:</li> <li>reddit</li></ul><p class="unprintable"><p>A few days ago, my article Why Continuous Integration Doesn’t Work was published at DevOps.com. Almost the same day I received a few strongly negative critiques on Twitter.</p><p>Here is my response to the un-asked question:</p><blockquote><p>Why the hell shouldn’t continuous integration work, being such a brilliant and popular idea?</p></blockquote><p>Even though I have some experience in this area, I won’t use it as an argument. I’ll try to rely only on logic instead.</p><p>BTW, my experience includes five years of using Apache Continuum, Hudson, CruiseControl, and Jenkins in over 50 open source and commercial projects. Besides that, a few years ago I created a hosted continuous integration service called fazend.com, renamed to rultor.com in 2013. Currently, I’m also an active user of Travis and AppVeyor.</p><h2 id="how-continuous-integration-should-work">How Continuous Integration Should Work</h2><aside class="youtube"> <div class="box">
<div class="play"></div></div><div>Continuous Integration is Dead; 24 April 2015.</div></aside><p>The idea is simple and obvious. Every time you make a new commit to the masterbranch (or/trunkin Subversion), a continuous integration server (or service) attempts to build the entire product. “Build” means compile, unit test, integration test, quality analysis, etc.</p><p>The result is either “success” or “failure.” If it is a success, we say that “the build is clean.” If it is a failure, we say that “the build is broken.” The build usually gets broken because someone breaks it by committing new code that turns previously passing unit tests into failing ones.</p><p>This is the technical side of the problem. It always works. Well, it may have its problems, like hard-coded dependencies, lack of isolation between environments or parallel build collisions, but this article is not about those. If the application is well written and its unit tests are stable, continuous integration is easy. Technically.</p><aside class="youtube"> <div class="box">
<div class="play"></div></div><div>Continuous Integration May Have Negative Effects; 20 April 2016.</div></aside><p>Let’s see the organizational side.</p><p>Continuous integration is not only a server that builds, but a management/organizational process that should “work.” Being a process that works means exactly what Jez Humble said in Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, on page 55:</p><blockquote><p>Crucially, if the build fails, the development team stops whatever they are doing and fixes the problem immediately</p></blockquote><p>This is what doesn’t work and can’t work.</p><h2 id="who-needs-this">Who Needs This?</h2><p>As we see, continuous integration is about setting the entire development team on pause and fixing the broken build. Let me reiterate. Once the build is broken, everybody should focus on fixing it and making a commit that returns the build to the stable state.</p><p>Now, my question is—who, in an actively working team, may need this?</p><p>A product owner, who is interested in launching new features to the market as soon as possible? Or maybe a project manager, who is responsible for the deadlines? Or maybe programmers, who hate to fix bugs made by someone else, especially under pressure?</p><p>Who likes this continuous integration and who needs it?</p><p>Nobody.</p><h2 id="what-happens-in-reality">What Happens In Reality?</h2><p>I can tell you. I’ve seen it multiple times. The scenario is always the same. We just start to ignore that continuous integration build status. Either the build is clean or it is broken, and we continue to do what we were doing before.</p><p>We don’t stop and fix it, as Jez Humble recommends.</p><p>Instead, we ignore the information that’s coming from the continuous integration server.</p><p>Eventually, maybe tomorrow or on Monday, we’ll try to find some spare time and will try to fix the build. Only because we don’t like that red button on the dashboard and want to turn it into a green one.</p><h2 id="what-about-discipline">What About Discipline?</h2><aside class="youtube"> <div class="box"> 
<div class="play"></div></div><div>Pre-flight Build Pitfalls; 10 May 2016.</div></aside><p>Yes, there is another side of this coin. We can try to enforce discipline in the team. We can make it a strict rule, that our build is always clean and whoever breaks it gets some sort of a punishment.</p><p>Try doing this and you will get a fear driven development. Programmers will be afraid of committing anything to the repository because they will know that if they cause a build failure they will have to apologize, at least.</p><p>A strict discipline (which I’m a big fan of) in this case only makes the situation worse. The entire development process slows down and programmers keep their code to themselves for as long as possible, to avoid possibly broken builds. When it’s time to commit, their changes are so massive that merging becomes very difficult and sometimes impossible.</p><p>As a result you get a lot of throw-away code, written by someone but never committed to master, because of that fear factor.</p><h2 id="ok-what-is-the-solution">OK, What Is The Solution?</h2><p>I wrote about it before; it is called read-only master branch.</p><p>It is simple—prohibit anyone from merging anything intomasterand create a script that anyone can call. The script will merge, test, and commit. The script will not make any exceptions. If any branch breaks at even one unit test, the entire branch will be rejected.</p><p>In other words: raise the red flag before the code gets intomaster.</p><p>This solves all problems.</p><p>First, the build is always clean. We simply can’t break it because nobody can commit unless his code keeps the build clean.</p><p>Second, there is no fear of breaking anything. Simply because you technically can’t do it. All you can do is get a negative response from a merging script. Then you fix your errors and tell the script to try again. Nobody sees these attempts, and you don’t need to apologize. Fear factor is gone.</p><p>BTW, try to use rultor.com to enforce this read-only master branch principle in your project.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>A few days ago, my article Why Continuous Integration Doesn’t Work was published at DevOps.com. Almost the same day I received a few strongly negative critiques on Twitter.</p><p>Here is my response to the un-asked question:</p><blockquote><p>Why the hell shouldn’t continuous integration work, being such a brilliant and popular idea?</p></blockquote><p>Even though I have some experience in this area, I won’t use it as an argument. I’ll try to rely only on logic instead.</p><p>BTW, my experience includes five years of using Apache Continuum, Hudson, CruiseControl, and Jenkins in over 50 open source and commercial projects. Besides that, a few years ago I created a hosted continuous integration service called fazend.com, renamed to rultor.com in 2013. Currently, I’m also an active user of Travis and AppVeyor.</p><h2 id="how-continuous-integration-should-work">How Continuous Integration Should Work</h2><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Continuous Integration is Dead; 24 April 2015.</div></aside><p>The idea is simple and obvious. Every time you make a new commit to the masterbranch (or/trunkin Subversion), a continuous integration server (or service) attempts to build the entire product. “Build” means compile, unit test, integration test, quality analysis, etc.</p><p>The result is either “success” or “failure.” If it is a success, we say that “the build is clean.” If it is a failure, we say that “the build is broken.” The build usually gets broken because someone breaks it by committing new code that turns previously passing unit tests into failing ones.</p><p>This is the technical side of the problem. It always works. Well, it may have its problems, like hard-coded dependencies, lack of isolation between environments or parallel build collisions, but this article is not about those. If the application is well written and its unit tests are stable, continuous integration is easy. Technically.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Continuous Integration May Have Negative Effects; 20 April 2016.</div></aside><p>Let’s see the organizational side.</p><p>Continuous integration is not only a server that builds, but a management/organizational process that should “work.” Being a process that works means exactly what Jez Humble said in Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, on page 55:</p><blockquote><p>Crucially, if the build fails, the development team stops whatever they are doing and fixes the problem immediately</p></blockquote><p>This is what doesn’t work and can’t work.</p><h2 id="who-needs-this">Who Needs This?</h2><p>As we see, continuous integration is about setting the entire development team on pause and fixing the broken build. Let me reiterate. Once the build is broken, everybody should focus on fixing it and making a commit that returns the build to the stable state.</p><p>Now, my question is—who, in an actively working team, may need this?</p><p>A product owner, who is interested in launching new features to the market as soon as possible? Or maybe a project manager, who is responsible for the deadlines? Or maybe programmers, who hate to fix bugs made by someone else, especially under pressure?</p><p>Who likes this continuous integration and who needs it?</p><p>Nobody.</p><h2 id="what-happens-in-reality">What Happens In Reality?</h2><p>I can tell you. I’ve seen it multiple times. The scenario is always the same. We just start to ignore that continuous integration build status. Either the build is clean or it is broken, and we continue to do what we were doing before.</p><p>We don’t stop and fix it, as Jez Humble recommends.</p><p>Instead, we ignore the information that’s coming from the continuous integration server.</p><p>Eventually, maybe tomorrow or on Monday, we’ll try to find some spare time and will try to fix the build. Only because we don’t like that red button on the dashboard and want to turn it into a green one.</p><h2 id="what-about-discipline">What About Discipline?</h2><aside class="youtube"> <div class="box"> <div class="play"></div></div><div>Pre-flight Build Pitfalls; 10 May 2016.</div></aside><p>Yes, there is another side of this coin. We can try to enforce discipline in the team. We can make it a strict rule, that our build is always clean and whoever breaks it gets some sort of a punishment.</p><p>Try doing this and you will get a fear driven development. Programmers will be afraid of committing anything to the repository because they will know that if they cause a build failure they will have to apologize, at least.</p><p>A strict discipline (which I’m a big fan of) in this case only makes the situation worse. The entire development process slows down and programmers keep their code to themselves for as long as possible, to avoid possibly broken builds. When it’s time to commit, their changes are so massive that merging becomes very difficult and sometimes impossible.</p><p>As a result you get a lot of throw-away code, written by someone but never committed to master, because of that fear factor.</p><h2 id="ok-what-is-the-solution">OK, What Is The Solution?</h2><p>I wrote about it before; it is called read-only master branch.</p><p>It is simple—prohibit anyone from merging anything intomasterand create a script that anyone can call. The script will merge, test, and commit. The script will not make any exceptions. If any branch breaks at even one unit test, the entire branch will be rejected.</p><p>In other words: raise the red flag before the code gets intomaster.</p><p>This solves all problems.</p><p>First, the build is always clean. We simply can’t break it because nobody can commit unless his code keeps the build clean.</p><p>Second, there is no fear of breaking anything. Simply because you technically can’t do it. All you can do is get a negative response from a merging script. Then you fix your errors and tell the script to try again. Nobody sees these attempts, and you don’t need to apologize. Fear factor is gone.</p><p>BTW, try to use rultor.com to enforce this read-only master branch principle in your project.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Stop Chatting, Start Coding </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/10/07/stop-chatting-start-coding.html>12 Best</li> <li /2014/10/07/stop-chatting-start-coding.html>All 292</li> <li /2014/10/07/stop-chatting-start-coding.html>Webinars</li> <li /2014/10/07/stop-chatting-start-coding.html>Talks</li> <li /2014/10/07/stop-chatting-start-coding.html>Books</li> <li /2014/10/07/stop-chatting-start-coding.html>Papers</li> <li /2014/10/07/stop-chatting-start-coding.html>Pets</li> <li /2014/10/07/stop-chatting-start-coding.html class=”highlighted”>Trainings</li> <li /2014/10/07/stop-chatting-start-coding.html>Award</li> <li /2014/10/07/stop-chatting-start-coding.html>Testimonials</li> <li /2014/10/07/stop-chatting-start-coding.html>Shift-M</li> <li /2014/10/07/stop-chatting-start-coding.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/10/07/stop-chatting-start-coding.html</p><h1 itemprop="name headline mainEntityOfPage">Stop Chatting, Start Coding</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable">
<figcaption id="8606fa0a">Barton Fink (1991) by Joel Coen</figcaption>
<div class="play"></div></div><div>XDSD: management without meetings; 13 February 2016.</div></aside><p>But that’s not all.</p><p>This principle also means that nobody is paid for anything except tasks explicitly assigned to him/her. Thus, when a programmer has a question about current design, specification, configuration, etc.—nobody will be interested in answering it. Why not? Because there is no payment attached to this. Answering questions in Skype, Slack, or HipChat, or by email is something that is not appreciated in XDSD in any way. The project simply doesn’t pay for this activity. That’s why none of our programmers do this.</p><p>More about this philosophy here: It’s Not a School!</p><p>We don’t use any (I mean it!) informal communication channels in XDSD projects. We don’t do meetings or conference calls. We never discuss any technical issues on Skype or by phone.</p><aside class="quote">Every hour spent by a team member is traceable to the line of code produced.</aside><p>So, how do we resolve problems and share information?</p><p>We use task tracking systems for that. When a developer has a question, he submits it as a new “ticket.” The project manager then picks it up and assigns it to another developer, who is able to answer it. Then, the answer goes back through the tracking system or directly into the source code.</p><p>The “question ticket” gets closed when its author is satisfied with the answer. When the ticket is closed, those who answered it get paid.</p><p>Using this model, we significantly improve project communications, by making them clean and transparent. We also save a lot of project funds, since every hour spent by a team member is traceable to the line of code he produced.</p><aside class="youtube"> <div class="box"> 
<div class="play"></div></div><div>Meetings-free Programming; 1 April 2016.</div></aside><p>You can see how this happens in action, for example, in this ticket (the project is open source; that’s why all communications are open): jcabi/jcabi-github#731. One Java developer is having a problem with his Git repository. Apparently he did something wrong and couldn’t solve the problem by himself. He asked for help by submitting a new bug to the project. He was paid for the bug report. Then, another team member was assigned to help him. He did, through a number of suggestions and instructions. In the end, the problem was solved, and he was also paid for the solution. In total, the project spent 45 minutes, and the problem was solved.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div > </div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Project Lifecycle in Zerocracy </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/10/06/software-project-lifecycle.html>12 Best</li> <li /2014/10/06/software-project-lifecycle.html>All 292</li> <li /2014/10/06/software-project-lifecycle.html>Webinars</li> <li /2014/10/06/software-project-lifecycle.html>Talks</li> <li /2014/10/06/software-project-lifecycle.html>Books</li> <li /2014/10/06/software-project-lifecycle.html>Papers</li> <li /2014/10/06/software-project-lifecycle.html>Pets</li> <li /2014/10/06/software-project-lifecycle.html class=”highlighted”>Trainings</li> <li /2014/10/06/software-project-lifecycle.html>Award</li> <li /2014/10/06/software-project-lifecycle.html>Testimonials</li> <li /2014/10/06/software-project-lifecycle.html>Shift-M</li> <li /2014/10/06/software-project-lifecycle.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/10/06/software-project-lifecycle.html</p><h1 itemprop="name headline mainEntityOfPage">Project Lifecycle in Zerocracy</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>In addition to being a hands-on programmer, I’m also co-founder and CTO of Zerocracy, a custom software development company. I play the role of a technical and management leader in all projects we work with.</p>
README.mdfile. What’s important is that the document should be under version control. We will modify it during the course of the project, very intensively. TheREADME.mdshould briefly identify main “actors” of the system and define the product scope.</p><p>Even though it is only half a page, the creation of this initial SRS document is the most important and the most expensive task in the entire project. We pay a lot of attention to this step. Usually this document is written by one of our system analysts in direct communication with the project sponsor. We can’t afford a mistake at this step.</p><p>Then, we invite a few new system analysts to the project. These guys are responsible for turning our initialREADMEinto a more complete and detailed specification. They start by asking questions, submitting them one by one as GitHub issues. Every question is addressed to the product owner. Using his/her answers, system analysts modify theREADMEdocument. Sometimes we’re using Requs.</p><p>At the end of the Thinking phase we estimate the size of the project, in Hits of Code. Using this HoC metric, we can roughly estimate a budget.</p><h2 id="building">Building</h2>
README, in a few working days. No matter how big the idea and how massive the planning development, the architect still has to create (build from scratch!) the product in, say, three days.</p><p>Besides building the software itself, the architect has to configure all basic DevOps processes, including: 1) automated testing and quality control, 2) deploying and releasing pipelines, 3) repository of artifacts, 4) continuous integration service, etc.</p><p>The result of this phase is a working software package, deployable to its destination and available for testers. Technical quality requirements are also defined at this phase.</p><p>More about the Building phase here: Nine Steps to Start a Software Project</p><h2 id="fixing">Fixing</h2>
masterbranch—all changes must pass through our quality controls and be merged intomasterby rultor.com, our merging bot.</p><p>Also important to mention is that all communications with the product owner and between programmers happen only through GitHub issues. We never use any chats, Skype, emails or conferencing software. We communicate only through tickets and comments in GitHub.</p><h2 id="using">Using</h2>
README.mdfile. What’s important is that the document should be under version control. We will modify it during the course of the project, very intensively. TheREADME.mdshould briefly identify main “actors” of the system and define the product scope.</p><p>Even though it is only half a page, the creation of this initial SRS document is the most important and the most expensive task in the entire project. We pay a lot of attention to this step. Usually this document is written by one of our system analysts in direct communication with the project sponsor. We can’t afford a mistake at this step.</p><p>Then, we invite a few new system analysts to the project. These guys are responsible for turning our initialREADMEinto a more complete and detailed specification. They start by asking questions, submitting them one by one as GitHub issues. Every question is addressed to the product owner. Using his/her answers, system analysts modify theREADMEdocument. Sometimes we’re using Requs.</p><p>At the end of the Thinking phase we estimate the size of the project, in Hits of Code. Using this HoC metric, we can roughly estimate a budget.</p><h2 id="building">Building</h2>README, in a few working days. No matter how big the idea and how massive the planning development, the architect still has to create (build from scratch!) the product in, say, three days.</p><p>Besides building the software itself, the architect has to configure all basic DevOps processes, including: 1) automated testing and quality control, 2) deploying and releasing pipelines, 3) repository of artifacts, 4) continuous integration service, etc.</p><p>The result of this phase is a working software package, deployable to its destination and available for testers. Technical quality requirements are also defined at this phase.</p><p>More about the Building phase here: Nine Steps to Start a Software Project</p><h2 id="fixing">Fixing</h2>masterbranch—all changes must pass through our quality controls and be merged intomasterby rultor.com, our merging bot.</p><p>Also important to mention is that all communications with the product owner and between programmers happen only through GitHub issues. We never use any chats, Skype, emails or conferencing software. We communicate only through tickets and comments in GitHub.</p><h2 id="using">Using</h2></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Best Hosted Continuous Integration Services for a Private Repository </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>12 Best</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>All 292</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Webinars</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Talks</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Books</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Papers</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Pets</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html class=”highlighted”>Trainings</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Award</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Testimonials</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Shift-M</li> <li /2014/10/05/ten-hosted-continuous-integration-services.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/10/05/ten-hosted-continuous-integration-services.html</p><h1 itemprop="name headline mainEntityOfPage">Best Hosted Continuous Integration Services for a Private Repository</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Every project I’m working with starts with a setup of continuous integration pipeline. I’m a big fan of cloud services, that’s why I was always using Travis. A few of my clients questioned this choice recently, mostly because of the price. So I decided to make a brief analysis of the market.</p><p>I configured Rultor, an open source project, in every CI service I managed to find. All of them are free for open source projects. All of them are hosted and do not require any server installation Here they are, in order of my personal preference (first four are the best and highly recommended):</p><table> <colgroup> <col class="x-col1" /> <col class="x-col2" /> <col class="x-colX" /> <col class="x-colX" /> <col class="x-colX" /> <col class="x-colX" /> <col class="x-colX" /> </colgroup> <thead> <tr class="x-head"><td></td><td class="x-bottom x-right">Minimum price</td><td class="x-vertical"><div>Linux1</div></td><td class="x-vertical"><div>Windows2</div></td><td class="x-vertical"><div>MacOS3</div></td><td class="x-vertical"><div>Pull requests4</div></td><td class="x-vertical"><div>Log compress5</div></td><td class="x-vertical"><div>Docker6</div></td><td class="x-bottom">Build</td></tr> </thead> <tbody> <tr><td>Shippable☺</td><td class="x-right">free (!)</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td></td></tr> <tr><td>Travis</td><td class="x-right">$69/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td>
</td></tr> <tr><td>AppVeyor</td><td class="x-right">$39/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center">?</td><td class="center">—</td><td> </td></tr> <tr><td>Wercker</td><td class="x-right">$350/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td>
</td></tr> <tr><td colspan="9" class="x-hr"></td></tr> <tr><td>SemaphoreApp</td><td class="x-right">$29/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td></tr> <tr><td>Snap-CI☺</td><td class="x-right">$30/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center">?</td><td class="center"></td></tr> <tr><td>Codeship☺</td><td class="x-right">$49/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center">?</td><td class="center"></td><td class="center"></td></tr> <tr><td>CircleCI☺</td><td class="x-right">$19/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td></tr> <tr><td>SonoLabs</td><td class="x-right">$15/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center">?</td><td class="center"></td></tr> <tr><td>DeployBot</td><td class="x-right">$15/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center">?</td><td class="center">?</td><td class="center"></td></tr> <tr><td>Vexor</td><td class="x-right">¢90/hr</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center">?</td><td class="center">?</td><td class="center"></td></tr> <tr><td>GreenHouseCI</td><td class="x-right">$49/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center">?</td><td class="center">?</td><td class="center"></td></tr> </tbody> </table><p>If you know any other good continuous integration services, email me, I’ll review and add them to this list. BTW, here is a “full” list of continuous integration software and services.</p><p>By the way, a few platforms from this list contacted me and asked to review them again. Some even offered me money to put them higher in the list (kidding). Anyway, it’s up to you to decide whether it’s a good sign or not (I think it’s good, they care about their PR). I marked them in the list with ☺ emoji.</p><h2 id="best-four">Best Four</h2>
.travis.ymlout of the box. The user interface is easy to navigate since it doesn’t have “settings” page at all (or I didn’t find it). Everything is configured viashippable.ymlfile in the repository. The service looks stable and robust, no complains so far. What is especially cool about them is that they allow you to build in a Docker container.</p>
.travis.yml)—you should do everything through a UI. They also support caching between builds.</p>
/etc—it is a show-stopper for us.</p><p>Codeship works fine, but their web UI looks a bit out-dated. Besides that, they promise to work with pull requests, but I didn’t manage to configure them. They simply don’t notify our pull requests in GitHub, even though they build them. Maybe I’ll find a way, so far it’s not clear.</p>
2 Some of them can build on Windows platform.
3 MacOS support means that an Objective-C/Swift product can be built there.
4 I mean GitHub pull request support here. Some of them can be integrated with GitHub and will build pull requests before they are merged. Build status will be visible in GitHub. A pretty convenient feature.
5 Logs compression is a critical feature, at least for me. Most of my logs are from Maven and withoutcol -bthey look too long and unreadable.
6 Looks like Docker containers must be supported by all of them, but unfortunately it’s not the case. Ideally, all builds should run in containers.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Every project I’m working with starts with a setup of continuous integration pipeline. I’m a big fan of cloud services, that’s why I was always using Travis. A few of my clients questioned this choice recently, mostly because of the price. So I decided to make a brief analysis of the market.</p><p>I configured Rultor, an open source project, in every CI service I managed to find. All of them are free for open source projects. All of them are hosted and do not require any server installation Here they are, in order of my personal preference (first four are the best and highly recommended):</p><table> <colgroup> <col class="x-col1" /> <col class="x-col2" /> <col class="x-colX" /> <col class="x-colX" /> <col class="x-colX" /> <col class="x-colX" /> <col class="x-colX" /> </colgroup> <thead> <tr class="x-head"><td></td><td class="x-bottom x-right">Minimum price</td><td class="x-vertical"><div>Linux1</div></td><td class="x-vertical"><div>Windows2</div></td><td class="x-vertical"><div>MacOS3</div></td><td class="x-vertical"><div>Pull requests4</div></td><td class="x-vertical"><div>Log compress5</div></td><td class="x-vertical"><div>Docker6</div></td><td class="x-bottom">Build</td></tr> </thead> <tbody> <tr><td>Shippable☺</td><td class="x-right">free (!)</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td></td></tr> <tr><td>AppVeyor</td><td class="x-right">$39/mo</td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center"></td><td class="center">?</td><td class="center">—</td><td> .travis.ymlout of the box. The user interface is easy to navigate since it doesn’t have “settings” page at all (or I didn’t find it). Everything is configured viashippable.ymlfile in the repository. The service looks stable and robust, no complains so far. What is especially cool about them is that they allow you to build in a Docker container.</p>.travis.yml)—you should do everything through a UI. They also support caching between builds.</p>/etc—it is a show-stopper for us.</p><p>Codeship works fine, but their web UI looks a bit out-dated. Besides that, they promise to work with pull requests, but I didn’t manage to configure them. They simply don’t notify our pull requests in GitHub, even though they build them. Maybe I’ll find a way, so far it’s not clear.</p>
2 Some of them can build on Windows platform.
3 MacOS support means that an Objective-C/Swift product can be built there.
4 I mean GitHub pull request support here. Some of them can be integrated with GitHub and will build pull requests before they are merged. Build status will be visible in GitHub. A pretty convenient feature.
5 Logs compression is a critical feature, at least for me. Most of my logs are from Maven and withoutcol -bthey look too long and unreadable.
6 Looks like Docker containers must be supported by all of them, but unfortunately it’s not the case. Ideally, all builds should run in containers.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Built-in Fake Objects </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/09/23/built-in-fake-objects.html>12 Best</li> <li /2014/09/23/built-in-fake-objects.html>All 292</li> <li /2014/09/23/built-in-fake-objects.html>Webinars</li> <li /2014/09/23/built-in-fake-objects.html>Talks</li> <li /2014/09/23/built-in-fake-objects.html>Books</li> <li /2014/09/23/built-in-fake-objects.html>Papers</li> <li /2014/09/23/built-in-fake-objects.html>Pets</li> <li /2014/09/23/built-in-fake-objects.html class=”highlighted”>Trainings</li> <li /2014/09/23/built-in-fake-objects.html>Award</li> <li /2014/09/23/built-in-fake-objects.html>Testimonials</li> <li /2014/09/23/built-in-fake-objects.html>Shift-M</li> <li /2014/09/23/built-in-fake-objects.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/09/23/built-in-fake-objects.html</p><h1 itemprop="name headline mainEntityOfPage">Built-in Fake Objects</h1><aside class='book'>Read more about this subject in Section 2.8
of my book</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>While mock objects are perfect instruments for unit testing, mocking through mock frameworks may turn your unit tests into an unmaintainable mess. Thanks to them we often hear that “mocking is bad” and “mocking is evil.”</p><p>The root cause of this complexity is that our objects are too big. They have many methods and these methods return other objects, which also have methods. When we pass a mock version of such an object as a parameter, we should make sure that all of its methods return valid objects.</p><p>This leads to inevitable complexity, which turns unit tests to waste almost impossible to maintain.</p><h2 id="object-hierarchy">Object Hierarchy</h2><p>Take the Regioninterface from jcabi-dynamo as an example (this snippet and all others in this article are simplified, for the sake of brevity):</p><pre> <p>Itspublic interface Region { Table table(String name); }</pre>table()method returns an instance of theTableinterface, which has its own methods:</p><pre> <p>Interfacepublic interface Table { Frame frame(); Item put(Attributes attrs); Region region(); }</pre>Frame, returned by theframe()method, also has its own methods. And so on. In order to create a properly mocked instance of interfaceRegion, one would normally create a dozen other mock objects. With Mockito it will look like this:</p><pre> <p>And all of this is just a scaffolding before the actual testing.</p><h2 id="sample-use-case">Sample Use Case</h2><p>Let’s say, you’re developing a project that uses jcabi-dynamo for managing data in DynamoDB. Your class may look similar to this:</p>public void testMe() { // many more lines here... Frame frame = Mockito.mock(Frame.class); Mockito.doReturn(...).when(frame).iterator(); Table table = Mockito.mock(Table.class); Mockito.doReturn(frame).when(table).frame(); Region region = Mockito.mock(Region.class); Mockito.doReturn(table).when(region).table(Mockito.anyString()); }</pre><pre> <p>You can imagine how difficult it will be to unit test this class, using Mockito, for example. First, we have to mock thepublic class Employee { private final String name; private final Region region; public Employee(String empl, Region dynamo) { this.name = empl; this.region = dynamo; } public Integer salary() { return Integer.parseInt( this.region .table("employees") .frame() .where("name", this.name) .iterator() .next() .get("salary") .getN() ); } }</pre>Regioninterface. Then, we have to mock aTableinterface and make sure it is returned by thetable()method. Then, we have to mock aFrameinterface, etc.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>What Fake Objects Are For? (webinar #8); 4 November 2015.</div></aside><p>The unit test will be much longer than the class itself. Besides that, its real purpose, which is to test the retrieval of an employee’s salary, will not be obvious to the reader.</p><p>Moreover, when we need to test a similar method of a similar class, we will need to restart this mocking from scratch. Again, multiple lines of code, which will look very similar to what we have already written.</p><h2 id="fake-classes">Fake Classes</h2><p>The solution is to create fake classes and ship them together with real classes. This is what jcabi-dynamo is doing. Just look at its JavaDoc. There is a package called com.jcabi.dynamo.mockthat contains only fake classes, suitable only for unit testing.</p><p>Even though their sole purpose is to optimize unit testing, we ship them together with production code, in the same JAR package.</p><p>This is what a test will look like, when a fake classMkRegionis used:</p><pre> <p>This test looks obvious to me. First, we create a fake DynamoDB region, which works on top ofpublic class EmployeeTest { public void canFetchSalaryFromDynamoDb() { Region region = new MkRegion( new H2Data().with( "employees", new String[] {"name"}, new String[] {"salary"} ) ); region.table("employees").put( new Attributes() .with("name", "Jeff") .with("salary", new AttributeValue().withN(50000)) ); Employee emp = new Employee("Jeff", region); assertThat(emp.salary(), equalTo(50000)); } }</pre>H2Datastorage (in-memory H2 database). The storage will be ready for a singleemployeestable with a hash keynameand a singlesalaryattribute.</p><aside class="youtube"> <div class="box">
<div class="play"></div></div><div>Built-in Fake Objects; 10 November 2016.</div></aside><p>Then, we put a record into the table, with a hash Jeffand a salary50000.</p><p>Finally, we create an instance of classEmployeeand check how it fetches the salary from DynamoDB.</p><p>I’m currently doing the same thing in almost every open source library I’m working with. I’m creating a collection of fake classes, that simplify testing inside the library and for its users.</p><p>BTW, a great article on the same subject: tl;dw: Stop mocking, start testing by Ned Batchelder.</p><p>PS. Check this out, on a very similar subject: Mocking of HTTP Server in Java.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>While mock objects are perfect instruments for unit testing, mocking through mock frameworks may turn your unit tests into an unmaintainable mess. Thanks to them we often hear that “mocking is bad” and “mocking is evil.”</p><p>The root cause of this complexity is that our objects are too big. They have many methods and these methods return other objects, which also have methods. When we pass a mock version of such an object as a parameter, we should make sure that all of its methods return valid objects.</p><p>This leads to inevitable complexity, which turns unit tests to waste almost impossible to maintain.</p><h2 id="object-hierarchy">Object Hierarchy</h2><p>Take theRegioninterface from jcabi-dynamo as an example (this snippet and all others in this article are simplified, for the sake of brevity):</p><pre> <p>Itspublic interface Region { Table table(String name); }</pre>table()method returns an instance of theTableinterface, which has its own methods:</p><pre> <p>Interfacepublic interface Table { Frame frame(); Item put(Attributes attrs); Region region(); }</pre>Frame, returned by theframe()method, also has its own methods. And so on. In order to create a properly mocked instance of interfaceRegion, one would normally create a dozen other mock objects. With Mockito it will look like this:</p><pre> <p>And all of this is just a scaffolding before the actual testing.</p><h2 id="sample-use-case">Sample Use Case</h2><p>Let’s say, you’re developing a project that uses jcabi-dynamo for managing data in DynamoDB. Your class may look similar to this:</p>public void testMe() { // many more lines here... Frame frame = Mockito.mock(Frame.class); Mockito.doReturn(...).when(frame).iterator(); Table table = Mockito.mock(Table.class); Mockito.doReturn(frame).when(table).frame(); Region region = Mockito.mock(Region.class); Mockito.doReturn(table).when(region).table(Mockito.anyString()); }</pre><pre> <p>You can imagine how difficult it will be to unit test this class, using Mockito, for example. First, we have to mock thepublic class Employee { private final String name; private final Region region; public Employee(String empl, Region dynamo) { this.name = empl; this.region = dynamo; } public Integer salary() { return Integer.parseInt( this.region .table("employees") .frame() .where("name", this.name) .iterator() .next() .get("salary") .getN() ); } }</pre>Regioninterface. Then, we have to mock aTableinterface and make sure it is returned by thetable()method. Then, we have to mock aFrameinterface, etc.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>What Fake Objects Are For? (webinar #8); 4 November 2015.</div></aside><p>The unit test will be much longer than the class itself. Besides that, its real purpose, which is to test the retrieval of an employee’s salary, will not be obvious to the reader.</p><p>Moreover, when we need to test a similar method of a similar class, we will need to restart this mocking from scratch. Again, multiple lines of code, which will look very similar to what we have already written.</p><h2 id="fake-classes">Fake Classes</h2><p>The solution is to create fake classes and ship them together with real classes. This is what jcabi-dynamo is doing. Just look at its JavaDoc. There is a package called com.jcabi.dynamo.mockthat contains only fake classes, suitable only for unit testing.</p><p>Even though their sole purpose is to optimize unit testing, we ship them together with production code, in the same JAR package.</p><p>This is what a test will look like, when a fake classMkRegionis used:</p><pre> <p>This test looks obvious to me. First, we create a fake DynamoDB region, which works on top ofpublic class EmployeeTest { public void canFetchSalaryFromDynamoDb() { Region region = new MkRegion( new H2Data().with( "employees", new String[] {"name"}, new String[] {"salary"} ) ); region.table("employees").put( new Attributes() .with("name", "Jeff") .with("salary", new AttributeValue().withN(50000)) ); Employee emp = new Employee("Jeff", region); assertThat(emp.salary(), equalTo(50000)); } }</pre>H2Datastorage (in-memory H2 database). The storage will be ready for a singleemployeestable with a hash keynameand a singlesalaryattribute.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Built-in Fake Objects; 10 November 2016.</div></aside><p>Then, we put a record into the table, with a hash Jeffand a salary50000.</p><p>Finally, we create an instance of classEmployeeand check how it fetches the salary from DynamoDB.</p><p>I’m currently doing the same thing in almost every open source library I’m working with. I’m creating a collection of fake classes, that simplify testing inside the library and for its users.</p><p>BTW, a great article on the same subject: tl;dw: Stop mocking, start testing by Ned Batchelder.</p><p>PS. Check this out, on a very similar subject: Mocking of HTTP Server in Java.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Getters/Setters. Evil. Period. </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/09/16/getters-and-setters-are-evil.html>12 Best</li> <li /2014/09/16/getters-and-setters-are-evil.html>All 292</li> <li /2014/09/16/getters-and-setters-are-evil.html>Webinars</li> <li /2014/09/16/getters-and-setters-are-evil.html>Talks</li> <li /2014/09/16/getters-and-setters-are-evil.html>Books</li> <li /2014/09/16/getters-and-setters-are-evil.html>Papers</li> <li /2014/09/16/getters-and-setters-are-evil.html>Pets</li> <li /2014/09/16/getters-and-setters-are-evil.html class=”highlighted”>Trainings</li> <li /2014/09/16/getters-and-setters-are-evil.html>Award</li> <li /2014/09/16/getters-and-setters-are-evil.html>Testimonials</li> <li /2014/09/16/getters-and-setters-are-evil.html>Shift-M</li> <li /2014/09/16/getters-and-setters-are-evil.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html</p><h1 itemprop="name headline mainEntityOfPage">Getters/Setters. Evil. Period.</h1><aside class='book'>Read more about this subject in Section 3.5
of my book</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="unprintable subline"> <li>Translated:</li> <li>Japanese</li> <li>Russian</li> <li>Polish</li> <li>add yours!</li></ul><ul class="subline"> <li>Discussed at:</li> <li>reddit</li></ul><p class="unprintable"><p>There is an old debate, started in 2003 by Allen Holub in this Why getter and setter methods are evil famous article, about whether getters/setters is an anti-pattern and should be avoided or if it is something we inevitably need in object-oriented programming. I’ll try to add my two cents to this discussion.</p><p>The gist of the following text is this: getters and setters is a terrible practice and those who use it can’t be excused. Again, to avoid any misunderstanding, I’m not saying that get/set should be avoided when possible. No. I’m saying that you should never have them near your code.</p>
<figcaption id="36b53fbe">A Fish Called Wanda (1988) by Charles Crichton</figcaption>
and setters), in an object-oriented world. All of them, I think, are not strong enough. Let’s briefly go through them.</p><p>Tell, Don’t Ask Allen Holub says, “Don’t ask for the information you need to do the work; ask the object that has the information to do the work for you.”</p><p>Violated Encapsulation Principle An object can be teared apart by other objects, since they are able to inject any new data into it, through setters. The object simply can’t encapsulate its own state safely enough, since anyone can alter it.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Why Getters-and-Setters Is An Anti-Pattern? (webinar #4); 1 July 2015.</div></aside><p>Exposed Implementation Details If we can get an object out of another object, we are relying too much on the first object’s implementation details. If tomorrow it will change, say, the type of that result, we have to change our code as well.</p><p>All these justifications are reasonable, but they are missing the main point.</p><h2 id="fundamental-disbelief">Fundamental Disbelief</h2><p>Most programmers believe that an object is a data structure with methods. I’m quoting Getters and Setters Are Not Evil, an article by Bozhidar Bozhanov:</p><blockquote><p>But the majority of objects for which people generate getters and setters are simple data holders.</p></blockquote><p>This misconception is the consequence of a huge misunderstanding! Objects are not “simple data holders.” Objects are not data structures with attached methods. This “data holder” concept came to object-oriented programming from procedural languages, especially C and COBOL. I’ll say it again: an object is not a set of data elements and functions that manipulate them. An object is not a data entity.</p><p>What is it then?</p><h2 id="a-ball-and-a-dog">A Ball and A Dog</h2><p>In true object-oriented programming, objects are living creatures, like you and me. They are living organisms, with their own behavior, properties and a life cycle.</p><p>Can a living organism have a setter? Can you “set” a ball to a dog? Not really. But that is exactly what the following piece of software is doing:</p><pre> <p>How does that sound?</p><p>Can you get a ball from a dog? Well, you probably can, if she ate it and you’re doing surgery. In that case, yes, we can “get” a ball from a dog. This is what I’m talking about:</p>Dog dog = new Dog(); dog.setBall(new Ball());</pre><pre> <p>Or an even more ridiculous example:</p>Dog dog = new Dog(); Ball ball = dog.getBall();</pre><pre> <p>Can you imagine this transaction in the real world? :)</p><aside class="youtube"> <div class="box">Dog dog = new Dog(); dog.setWeight("23kg");</pre>
<div class="play"></div></div><div>Object Oriented Lies (in Russian with English subtitles); 24 April 2016.</div></aside><p>Does it look similar to what you’re writing every day? If yes, then you’re a procedural programmer. Admit it. And this is what David West has to say about it, on page 30 of his book:</p><blockquote><p>Step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy.</p></blockquote><p>Do you need a lobotomy? Well, I definitely needed one and received it, while reading West’s Object Thinking.</p><h2 id="object-thinking">Object Thinking</h2><p>Start thinking like an object and you will immediately rename those methods. This is what you will probably get:</p><pre> <p>Now, we’re treating the dog as a real animal, who can take a ball from us and can give it back, when we ask. Worth mentioning is that the dog can’t giveDog dog = new Dog(); dog.take(new Ball()); Ball ball = dog.give();</pre>NULLback. Dogs simply don’t know whatNULLis :) Object thinking immediately eliminates NULL references from your code.</p><p>Besides that, object thinking will lead to object immutability, like in the “weight of the dog” example. You would re-write that like this instead:</p><pre> <p>The dog is an immutable living organism, which doesn’t allow anyone from the outside to change her weight, or size, or name, etc. She can tell, on request, her weight or name. There is nothing wrong with public methods that demonstrate requests for certain “insides” of an object. But these methods are not “getters” and they should never have the “get” prefix. We’re not “getting” anything from the dog. We’re not getting her name. We’re asking her to tell us her name. See the difference?</p><p>We’re not talking semantics here, either. We are differentiating the procedural programming mindset from an object-oriented one. In procedural programming, we’re working with data, manipulating them, getting, setting, and deleting when necessary. We’re in charge, and the data is just a passive component. The dog is nothing to us—it’s just a “data holder.” It doesn’t have its own life. We are free to get whatever is necessary from it and set any data into it. This is how C, COBOL, Pascal and many other procedural languages work(ed).</p><p>On the contrary, in a true object-oriented world, we treat objects like living organisms, with their own date of birth and a moment of death—with their own identity and habits, if you wish. We can ask a dog to give us some piece of data (for example, her weight), and she may return us that information. But we always remember that the dog is an active component. She decides what will happen after our request.</p><p>That’s why, it is conceptually incorrect to have any methods starting withDog dog = new Dog("23kg"); int weight = dog.weight();</pre>setorgetin an object. And it’s not about breaking encapsulation, like many people argue. It is whether you’re thinking like an object or you’re still writing COBOL in Java syntax.</p><p>PS. Yes, you may ask,—what about JavaBeans, JPA, JAXB, and many other Java API-s that rely on the get/set notation? What about Ruby’s built-in feature that simplifies the creation of accessors? Well, all of that is our misfortune. It is much easier to stay in a primitive world of procedural COBOL than to truly understand and appreciate the beautiful world of true objects.</p><p>PPS. Forgot to say, yes, dependency injection via setters is also a terrible anti-pattern. About it, in one of the next posts :)</p><p>PPPS. Here is what I’m suggesting to use instead of getters: printers.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>There is an old debate, started in 2003 by Allen Holub in this Why getter and setter methods are evil famous article, about whether getters/setters is an anti-pattern and should be avoided or if it is something we inevitably need in object-oriented programming. I’ll try to add my two cents to this discussion.</p><p>The gist of the following text is this: getters and setters is a terrible practice and those who use it can’t be excused. Again, to avoid any misunderstanding, I’m not saying that get/set should be avoided when possible. No. I’m saying that you should never have them near your code.</p>and setters), in an object-oriented world. All of them, I think, are not strong enough. Let’s briefly go through them.</p><p>Tell, Don’t Ask Allen Holub says, “Don’t ask for the information you need to do the work; ask the object that has the information to do the work for you.”</p><p>Violated Encapsulation Principle An object can be teared apart by other objects, since they are able to inject any new data into it, through setters. The object simply can’t encapsulate its own state safely enough, since anyone can alter it.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Why Getters-and-Setters Is An Anti-Pattern? (webinar #4); 1 July 2015.</div></aside><p>Exposed Implementation Details If we can get an object out of another object, we are relying too much on the first object’s implementation details. If tomorrow it will change, say, the type of that result, we have to change our code as well.</p><p>All these justifications are reasonable, but they are missing the main point.</p><h2 id="fundamental-disbelief">Fundamental Disbelief</h2><p>Most programmers believe that an object is a data structure with methods. I’m quoting Getters and Setters Are Not Evil, an article by Bozhidar Bozhanov:</p><blockquote><p>But the majority of objects for which people generate getters and setters are simple data holders.</p></blockquote><p>This misconception is the consequence of a huge misunderstanding! Objects are not “simple data holders.” Objects are not data structures with attached methods. This “data holder” concept came to object-oriented programming from procedural languages, especially C and COBOL. I’ll say it again: an object is not a set of data elements and functions that manipulate them. An object is not a data entity.</p><p>What is it then?</p><h2 id="a-ball-and-a-dog">A Ball and A Dog</h2><p>In true object-oriented programming, objects are living creatures, like you and me. They are living organisms, with their own behavior, properties and a life cycle.</p><p>Can a living organism have a setter? Can you “set” a ball to a dog? Not really. But that is exactly what the following piece of software is doing:</p><pre> <p>How does that sound?</p><p>Can you get a ball from a dog? Well, you probably can, if she ate it and you’re doing surgery. In that case, yes, we can “get” a ball from a dog. This is what I’m talking about:</p>Dog dog = new Dog(); dog.setBall(new Ball());</pre><pre> <p>Or an even more ridiculous example:</p>Dog dog = new Dog(); Ball ball = dog.getBall();</pre><pre> <p>Can you imagine this transaction in the real world? :)</p><aside class="youtube"> <div class="box">Dog dog = new Dog(); dog.setWeight("23kg");</pre><div class="play"></div></div><div>Object Oriented Lies (in Russian with English subtitles); 24 April 2016.</div></aside><p>Does it look similar to what you’re writing every day? If yes, then you’re a procedural programmer. Admit it. And this is what David West has to say about it, on page 30 of his book:</p><blockquote><p>Step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy.</p></blockquote><p>Do you need a lobotomy? Well, I definitely needed one and received it, while reading West’s Object Thinking.</p><h2 id="object-thinking">Object Thinking</h2><p>Start thinking like an object and you will immediately rename those methods. This is what you will probably get:</p><pre> <p>Now, we’re treating the dog as a real animal, who can take a ball from us and can give it back, when we ask. Worth mentioning is that the dog can’t giveDog dog = new Dog(); dog.take(new Ball()); Ball ball = dog.give();</pre>NULLback. Dogs simply don’t know whatNULLis :) Object thinking immediately eliminates NULL references from your code.</p><p>Besides that, object thinking will lead to object immutability, like in the “weight of the dog” example. You would re-write that like this instead:</p><pre> <p>The dog is an immutable living organism, which doesn’t allow anyone from the outside to change her weight, or size, or name, etc. She can tell, on request, her weight or name. There is nothing wrong with public methods that demonstrate requests for certain “insides” of an object. But these methods are not “getters” and they should never have the “get” prefix. We’re not “getting” anything from the dog. We’re not getting her name. We’re asking her to tell us her name. See the difference?</p><p>We’re not talking semantics here, either. We are differentiating the procedural programming mindset from an object-oriented one. In procedural programming, we’re working with data, manipulating them, getting, setting, and deleting when necessary. We’re in charge, and the data is just a passive component. The dog is nothing to us—it’s just a “data holder.” It doesn’t have its own life. We are free to get whatever is necessary from it and set any data into it. This is how C, COBOL, Pascal and many other procedural languages work(ed).</p><p>On the contrary, in a true object-oriented world, we treat objects like living organisms, with their own date of birth and a moment of death—with their own identity and habits, if you wish. We can ask a dog to give us some piece of data (for example, her weight), and she may return us that information. But we always remember that the dog is an active component. She decides what will happen after our request.</p><p>That’s why, it is conceptually incorrect to have any methods starting withDog dog = new Dog("23kg"); int weight = dog.weight();</pre>setorgetin an object. And it’s not about breaking encapsulation, like many people argue. It is whether you’re thinking like an object or you’re still writing COBOL in Java syntax.</p><p>PS. Yes, you may ask,—what about JavaBeans, JPA, JAXB, and many other Java API-s that rely on the get/set notation? What about Ruby’s built-in feature that simplifies the creation of accessors? Well, all of that is our misfortune. It is much easier to stay in a primitive world of procedural COBOL than to truly understand and appreciate the beautiful world of true objects.</p><p>PPS. Forgot to say, yes, dependency injection via setters is also a terrible anti-pattern. About it, in one of the next posts :)</p><p>PPPS. Here is what I’m suggesting to use instead of getters: printers.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Deployment Script vs. Rultor </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/09/11/deployment-script-vs-rultor.html>12 Best</li> <li /2014/09/11/deployment-script-vs-rultor.html>All 292</li> <li /2014/09/11/deployment-script-vs-rultor.html>Webinars</li> <li /2014/09/11/deployment-script-vs-rultor.html>Talks</li> <li /2014/09/11/deployment-script-vs-rultor.html>Books</li> <li /2014/09/11/deployment-script-vs-rultor.html>Papers</li> <li /2014/09/11/deployment-script-vs-rultor.html>Pets</li> <li /2014/09/11/deployment-script-vs-rultor.html class=”highlighted”>Trainings</li> <li /2014/09/11/deployment-script-vs-rultor.html>Award</li> <li /2014/09/11/deployment-script-vs-rultor.html>Testimonials</li> <li /2014/09/11/deployment-script-vs-rultor.html>Shift-M</li> <li /2014/09/11/deployment-script-vs-rultor.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/09/11/deployment-script-vs-rultor.html</p><h1 itemprop="name headline mainEntityOfPage">Deployment Script vs. Rultor</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable">
<figcaption id="2ee88f79">Charlie and the Chocolate Factory (2005) by Tim Burton</figcaption>
<div class="play"></div></div><div>Deployment Scripts Are Dead. Meet Rultor.; 26 May 2016.</div></aside><p>The first advantage you get once you start calling your deployment scripts from Rultor is the usage of Docker. I’m sure you know what Docker is, but for those who don’t—it is a manager of virtual Linux “machines.” It’s a command line script that you call when you need to run some script in a new virtual machine (aka “container”). Docker starts the container almost immediately and runs your script. The beauty of Docker is that every container is a perfectly isolated Linux environment, with its own file system, memory, processes, etc.</p><p>When you tell Rultor to run your deployment script, it starts a new Docker container and runs your script there. But what benefit does this give me, you ask?</p><p>The main benefit is that the container gets destroyed right after your script is done. This means that you can do all pre-configuration inside the container without any fear of conflict with your main working platform. Let me give an example.</p><p>I’m developing on MacBook, where I install and remove packages which I need for development. At the same time, I have a project that, in order to be deployed, requires PHP 5.3, MySQL 5.6, Phing, PHPUnit, PHPCS and xdebug. Every MacOS version needs to be configured specifically to get these applications up and running, and it’s a time-consuming job.</p><p>I can change laptops, and I can change MacOS versions, but the project stays the same. It still requires the same set of packages in order to run its deployment script successfully. And the project is not in active development any more. I simply don’t need these packages for my day-to-day work, since I’m working with Java more now. But, when I need to make a minor fix to that PHP project and deploy it, I have to install all the required PHP packages and configure them. Only after that can I deploy that minor fix.</p><p>It is annoying, to say the least.</p><p>Docker gives me the ability to automate all of this together. My existing deployment script will get a preamble, which will install and configure all necessary PHP-related packages in a clean Ubuntu container. This preamble will be executed on every run of my deployment script, inside a Docker container. For example, it may look like this:</p><p>My deployment script looked like this before I started to use Rultor:</p><pre> <p>Just two lines. The first one is a full run of unit tests. The second one is an FTP deployment to the production server. Very simple. But this script will only work if PHP 5.3, MySQL, Phing, xdebug, PHPCS and PHPUnit are installed. Again, it’s a lot of work to install and configure them every time I upgrade my MacOS or change a laptop.</p><aside class="youtube"> <div class="box">#!/bin/bash phing test git ftp push --user ".." \ --passwd ".." \ --syncroot php/src \ ftp://ftp.example.com/</pre>
<div class="play"></div></div><div>Practical Example of a One-Click Release; 15 November 2016.</div></aside><p>Needless to say, that if/when someone joins the project and tries to run my scripts, he/she will have to do this pre-installation work again.</p><p>So, here is a new script, which I’m using now. It is being executed inside a new Docker container, every time:</p><pre> <p>Obviously, running this script on my MacBook (without virtualization) would cause a lot of trouble. Well, I don’t even have#!/bin/bash # First, we install all prerequisites sudo apt-get install -y php5 php5-mysql mysql sudo apt-get install php-pear sudo pear channel-discover pear.phpunit.de sudo pear install phpunit/PHPUnit sudo pear install PHP_CodeSniffer sudo pecl install xdebug sudo pear channel-discover pear.phing.info sudo pear install phing/phing # And now the same script I had before phing test git ftp push --user ".." \ --passwd ".." \ --syncroot php/src \ ftp://ftp.example.com/</pre>apt-gethere :)</p><p>Thus, the first benefit that Rultor gives you is an isolation of your deployment script in its own virtual environment. We have this mostly thanks to Docker.</p><h2 id="visibility-of-logs">Visibility of Logs</h2><p>Traditionally, we keep deployment scripts in some~/deploydirectory and run them with a magic set of parameters. In a small project, you do this yourself and this directory is on your own laptop. In a bigger project, there is a “deployment” server, that has that magic directory with a set of scripts that can be executed only by a few trusted senior developers. I’ve seen this setup many times.</p><p>The biggest issue here is traceability. It’s almost impossible to find out who deployed what and why some particular deployment failed. The senior deployment gurus simply SSH to the server and run those magic scripts with magic parameters. Logs are usually lost and problem tracking is very difficult or impossible.</p><p>Rultor offers something different. With Rultor, there is no SSH access to deployment scripts any more. All scripts stay in the.rultor.ymlconfiguration file, and you start them by posting messages in your issue tracking system (for example GitHub, JIRA or Trac). Rultor runs the script and publishes its full log right to your ticket. The log stays with your project forever. You can always get back to the ticket you were working with and check why deployment failed and what instructions were actually executed.</p><p>For example, check out this GitHub issue, where I was deploying a new version of Rultor itself, and failed a few times: yegor256/rultor#563. All my failed attempts are protocolled. I can always get back to them and investigate. For a big project this information is vital.</p><p>Thus, the second benefit of Rultor versus a standalone deployment script is visibility of every single operation.</p><h2 id="security-of-credentials">Security of Credentials</h2><p>When you have a custom script sitting in your laptop or in that secret team deployment server, your production credentials stay close to it. There is just no other way. If your software works with a database, it has to know login credentials (user name, password, DB name, port number, etc.). Well, in the worst case, some people just hard code that information right into the source code. We aren’t even going to discuss this case, that’s how bad it is.</p><p>But let’s say you separate your DB credentials from the source code. You will have something like adb.propertiesordb.inifile, which will be attached to the application right before deployment. You can also keep that file directly in the production server, which is even better, but not always possible, especially with PaaS deployments, for example.</p><p>A similar problem exists with deployments of artifacts to repositories. Say, you’re regularly deploying to RubyGems.org. Your~/.gem/credentialswill contain your secret API key.</p><p>So, very often, your deployment scripts are accompanied by some files with sensitive and secure information. And these files have this information in a plain, open format. No encryption, no protection. Just user names, passwords, codes and tokens in plain text.</p><p>Why is this bad? Well, for a single developer with a single laptop this doesn’t sound like a problem. Although, I don’t like the idea of losing a laptop somewhere in an airport with all credentials open and ready to be used. You may argue that there are disc protection tools, like FileVault for MacOS or BestCrypt for Windows. Yes, maybe.</p><p>But let’s see what happens when we have a team of developers, working together and sharing those deployment scripts and files with credentials. Once you give access to your deployment scripts to a new member of the team, you have to share all that sensitive data. There is just no way around it. In order to use the scripts he/she has to be able to open files with credentials.</p><p>This is a problem, if you care about the security of your data.</p><p>Rultor solves this problem by offering an on-the-fly GPG decryption of your sensitive data, right before they are used by your deployment scripts. In the.rultor.ymlconfiguration file you just say:</p><pre> <p>Then, you encrypt yourdecrypt: db.ini: "repo/db.ini.asc" deploy: script: ftp put db.ini production</pre>db.iniusing a Rultor GPG key, and fearlessly commitdb.ini.ascto the repository. Nobody will be able to open and read that file, except the Rultor server itself, right before running the deployment script.</p><p>Thus, the third benefit of Rultor versus a standalone deployment script is proper security of sensitive data.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><pre> <p>Just two lines. The first one is a full run of unit tests. The second one is an FTP deployment to the production server. Very simple. But this script will only work if PHP 5.3, MySQL, Phing, xdebug, PHPCS and PHPUnit are installed. Again, it’s a lot of work to install and configure them every time I upgrade my MacOS or change a laptop.</p><aside class="youtube"> <div class="box">#!/bin/bash phing test git ftp push --user ".." \ --passwd ".." \ --syncroot php/src \ ftp://ftp.example.com/</pre><div class="play"></div></div><div>Practical Example of a One-Click Release; 15 November 2016.</div></aside><p>Needless to say, that if/when someone joins the project and tries to run my scripts, he/she will have to do this pre-installation work again.</p><p>So, here is a new script, which I’m using now. It is being executed inside a new Docker container, every time:</p><pre> <p>Obviously, running this script on my MacBook (without virtualization) would cause a lot of trouble. Well, I don’t even have#!/bin/bash # First, we install all prerequisites sudo apt-get install -y php5 php5-mysql mysql sudo apt-get install php-pear sudo pear channel-discover pear.phpunit.de sudo pear install phpunit/PHPUnit sudo pear install PHP_CodeSniffer sudo pecl install xdebug sudo pear channel-discover pear.phing.info sudo pear install phing/phing # And now the same script I had before phing test git ftp push --user ".." \ --passwd ".." \ --syncroot php/src \ ftp://ftp.example.com/</pre>apt-gethere :)</p><p>Thus, the first benefit that Rultor gives you is an isolation of your deployment script in its own virtual environment. We have this mostly thanks to Docker.</p><h2 id="visibility-of-logs">Visibility of Logs</h2><p>Traditionally, we keep deployment scripts in some~/deploydirectory and run them with a magic set of parameters. In a small project, you do this yourself and this directory is on your own laptop. In a bigger project, there is a “deployment” server, that has that magic directory with a set of scripts that can be executed only by a few trusted senior developers. I’ve seen this setup many times.</p><p>The biggest issue here is traceability. It’s almost impossible to find out who deployed what and why some particular deployment failed. The senior deployment gurus simply SSH to the server and run those magic scripts with magic parameters. Logs are usually lost and problem tracking is very difficult or impossible.</p><p>Rultor offers something different. With Rultor, there is no SSH access to deployment scripts any more. All scripts stay in the.rultor.ymlconfiguration file, and you start them by posting messages in your issue tracking system (for example GitHub, JIRA or Trac). Rultor runs the script and publishes its full log right to your ticket. The log stays with your project forever. You can always get back to the ticket you were working with and check why deployment failed and what instructions were actually executed.</p><p>For example, check out this GitHub issue, where I was deploying a new version of Rultor itself, and failed a few times: yegor256/rultor#563. All my failed attempts are protocolled. I can always get back to them and investigate. For a big project this information is vital.</p><p>Thus, the second benefit of Rultor versus a standalone deployment script is visibility of every single operation.</p><h2 id="security-of-credentials">Security of Credentials</h2><p>When you have a custom script sitting in your laptop or in that secret team deployment server, your production credentials stay close to it. There is just no other way. If your software works with a database, it has to know login credentials (user name, password, DB name, port number, etc.). Well, in the worst case, some people just hard code that information right into the source code. We aren’t even going to discuss this case, that’s how bad it is.</p><p>But let’s say you separate your DB credentials from the source code. You will have something like adb.propertiesordb.inifile, which will be attached to the application right before deployment. You can also keep that file directly in the production server, which is even better, but not always possible, especially with PaaS deployments, for example.</p><p>A similar problem exists with deployments of artifacts to repositories. Say, you’re regularly deploying to RubyGems.org. Your~/.gem/credentialswill contain your secret API key.</p><p>So, very often, your deployment scripts are accompanied by some files with sensitive and secure information. And these files have this information in a plain, open format. No encryption, no protection. Just user names, passwords, codes and tokens in plain text.</p><p>Why is this bad? Well, for a single developer with a single laptop this doesn’t sound like a problem. Although, I don’t like the idea of losing a laptop somewhere in an airport with all credentials open and ready to be used. You may argue that there are disc protection tools, like FileVault for MacOS or BestCrypt for Windows. Yes, maybe.</p><p>But let’s see what happens when we have a team of developers, working together and sharing those deployment scripts and files with credentials. Once you give access to your deployment scripts to a new member of the team, you have to share all that sensitive data. There is just no way around it. In order to use the scripts he/she has to be able to open files with credentials.</p><p>This is a problem, if you care about the security of your data.</p><p>Rultor solves this problem by offering an on-the-fly GPG decryption of your sensitive data, right before they are used by your deployment scripts. In the.rultor.ymlconfiguration file you just say:</p><pre> <p>Then, you encrypt yourdecrypt: db.ini: "repo/db.ini.asc" deploy: script: ftp put db.ini production</pre>db.iniusing a Rultor GPG key, and fearlessly commitdb.ini.ascto the repository. Nobody will be able to open and read that file, except the Rultor server itself, right before running the deployment script.</p><p>Thus, the third benefit of Rultor versus a standalone deployment script is proper security of sensitive data.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> RESTful API and a Web Site in the Same URL </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/09/09/restful-web-sites.html>12 Best</li> <li /2014/09/09/restful-web-sites.html>All 292</li> <li /2014/09/09/restful-web-sites.html>Webinars</li> <li /2014/09/09/restful-web-sites.html>Talks</li> <li /2014/09/09/restful-web-sites.html>Books</li> <li /2014/09/09/restful-web-sites.html>Papers</li> <li /2014/09/09/restful-web-sites.html>Pets</li> <li /2014/09/09/restful-web-sites.html class=”highlighted”>Trainings</li> <li /2014/09/09/restful-web-sites.html>Award</li> <li /2014/09/09/restful-web-sites.html>Testimonials</li> <li /2014/09/09/restful-web-sites.html>Shift-M</li> <li /2014/09/09/restful-web-sites.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/09/09/restful-web-sites.html</p><h1 itemprop="name headline mainEntityOfPage">RESTful API and a Web Site in the Same URL</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Look at GitHub RESTful API, for example. To get information about a repository you should make a GET request to api.github.com/repos/yegor256/rultor. In response, you will get a JSON document with all the details of theyegor256/rultorrepository. Try it, the URL doesn’t require any authentication.</p><p>To open the same repository in a nice HTML+CSS page, you should use a different URL: github.com/yegor256/rultor. The URL is different, the server-side is definitely different, but the nature of the data is exactly the same. The only thing that changes is a representation layer.</p><p>In the first case, we get JSON; in the second—HTML.</p><p>How about combining them? How about using the same URL and the same server-side processing mechanism for both of them? How about shifting the whole rendering task to the client-side (the browser) and letting the server work solely with the data?</p>
<figcaption id="a51703b7">The Good, the Bad, The Wierd (2008) by Kim Jee-woon</figcaption>GETandPOSTHTTP methods, while traditional RESTful API-s exploit also, at least,PUTandDELETE.</p></li> </ol><p>The first problem is not really a problem. It’s just a matter of taste (and level of education). The last two problems are much more serious. Let’s discuss them.</p><h2 id="xsl-transformation-on-the-server">XSL Transformation on the Server</h2><p>XSLT is not supported by some browsers. How do we solve this?</p><p>I think that the best approach is to parse theUser-AgentHTTP header in every request and make a guess, whether this particular version of the browser supports XSLT or not. It’s not so difficult to do, since this compatibility information is public.</p><p>If the browser doesn’t support XSLT, we can do the transformation on the server side. We already have the XML with data, generated by the server, and we already have the XSL attached to it. All we need to do is to apply the latter to the former and obtain an HTML page. Then, we return the HTML to the browser.</p><p>Besides that, we can also pay attention to theAcceptheader. If it is set toapplication/xmlortext/xml, we return XML, no matter whatUser-Agentis saying. This means, basically, that some API client is talking to us, not a browser. And this client is not interested in HTML, but in pure data in XML format.</p><h2 id="post-instead-of-put">POST Instead of PUT</h2><p>There is no workaround for this. Browsers don’t know anything aboutPUTorDELETE. So, we should also forget them in our RESTful API-s. We should design our API using only two methods:GETandPOST. Is this even possible? Yes. Why not? It won’t look as fancy as with all six methods (some API-s also useOPTIONSandHEAD), but it will work.</p><h2 id="what-do-we-gain">What Do We Gain?</h2><p>OK, here is the question—why do we need this? What’s wrong with the way most people work now? Why can’t we make a web site separate from the API? What benefits do we get if we combine them?</p><p>I’ve been combining them in all web applications I’ve worked with since 2011. And the biggest advantage I’m experiencing is avoiding code duplication.</p><p>It is obvious that in the server we don’t duplicate controllers (in the case of MVC). We have one layer of controllers, and they control both the API and the web site (since they are one thing now).</p><p>Avoiding code duplication is a very important achievement. Moreover, I believe that it is the most important target for any software project.</p><p>These small web apps work exactly as explained above: s3auth.com, stateful.co, bibrarian.com. They are all open source, and you can see their source code in GitHub.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Look at GitHub RESTful API, for example. To get information about a repository you should make a GET request to api.github.com/repos/yegor256/rultor. In response, you will get a JSON document with all the details of theyegor256/rultorrepository. Try it, the URL doesn’t require any authentication.</p><p>To open the same repository in a nice HTML+CSS page, you should use a different URL: github.com/yegor256/rultor. The URL is different, the server-side is definitely different, but the nature of the data is exactly the same. The only thing that changes is a representation layer.</p><p>In the first case, we get JSON; in the second—HTML.</p><p>How about combining them? How about using the same URL and the same server-side processing mechanism for both of them? How about shifting the whole rendering task to the client-side (the browser) and letting the server work solely with the data?</p>GETandPOSTHTTP methods, while traditional RESTful API-s exploit also, at least,PUTandDELETE.</p></li> </ol><p>The first problem is not really a problem. It’s just a matter of taste (and level of education). The last two problems are much more serious. Let’s discuss them.</p><h2 id="xsl-transformation-on-the-server">XSL Transformation on the Server</h2><p>XSLT is not supported by some browsers. How do we solve this?</p><p>I think that the best approach is to parse theUser-AgentHTTP header in every request and make a guess, whether this particular version of the browser supports XSLT or not. It’s not so difficult to do, since this compatibility information is public.</p><p>If the browser doesn’t support XSLT, we can do the transformation on the server side. We already have the XML with data, generated by the server, and we already have the XSL attached to it. All we need to do is to apply the latter to the former and obtain an HTML page. Then, we return the HTML to the browser.</p><p>Besides that, we can also pay attention to theAcceptheader. If it is set toapplication/xmlortext/xml, we return XML, no matter whatUser-Agentis saying. This means, basically, that some API client is talking to us, not a browser. And this client is not interested in HTML, but in pure data in XML format.</p><h2 id="post-instead-of-put">POST Instead of PUT</h2><p>There is no workaround for this. Browsers don’t know anything aboutPUTorDELETE. So, we should also forget them in our RESTful API-s. We should design our API using only two methods:GETandPOST. Is this even possible? Yes. Why not? It won’t look as fancy as with all six methods (some API-s also useOPTIONSandHEAD), but it will work.</p><h2 id="what-do-we-gain">What Do We Gain?</h2><p>OK, here is the question—why do we need this? What’s wrong with the way most people work now? Why can’t we make a web site separate from the API? What benefits do we get if we combine them?</p><p>I’ve been combining them in all web applications I’ve worked with since 2011. And the biggest advantage I’m experiencing is avoiding code duplication.</p><p>It is obvious that in the server we don’t duplicate controllers (in the case of MVC). We have one layer of controllers, and they control both the API and the web site (since they are one thing now).</p><p>Avoiding code duplication is a very important achievement. Moreover, I believe that it is the most important target for any software project.</p><p>These small web apps work exactly as explained above: s3auth.com, stateful.co, bibrarian.com. They are all open source, and you can see their source code in GitHub.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Simple Java SSH Client </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/09/02/java-ssh-client.html>12 Best</li> <li /2014/09/02/java-ssh-client.html>All 292</li> <li /2014/09/02/java-ssh-client.html>Webinars</li> <li /2014/09/02/java-ssh-client.html>Talks</li> <li /2014/09/02/java-ssh-client.html>Books</li> <li /2014/09/02/java-ssh-client.html>Papers</li> <li /2014/09/02/java-ssh-client.html>Pets</li> <li /2014/09/02/java-ssh-client.html class=”highlighted”>Trainings</li> <li /2014/09/02/java-ssh-client.html>Award</li> <li /2014/09/02/java-ssh-client.html>Testimonials</li> <li /2014/09/02/java-ssh-client.html>Shift-M</li> <li /2014/09/02/java-ssh-client.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/09/02/java-ssh-client.html</p><h1 itemprop="name headline mainEntityOfPage">Simple Java SSH Client</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>An execution of a shell command via SSH can be done in Java, in just a few lines, usingjcabi-ssh:</p><pre> <p>String hello = new Shell.Plain( new SSH( "ssh.example.com", 22, "yegor", "-----BEGIN RSA PRIVATE KEY-----..." ) ).exec("echo 'Hello, world!'");</pre>jcabi-sshis a convenient wrapper ofJSch, a well-known pure Java implementation of SSH2.</p><p>Here is a more complex scenario, where I upload a file via SSH and then read back its grepped content:</p><pre> <p>ClassShell shell = new SSH( "ssh.example.com", 22, "yegor", "-----BEGIN RSA PRIVATE KEY-----..." ); File file = new File("/tmp/data.txt"); new Shell.Safe(shell).exec( "cat > d.txt && grep 'some text' d.txt", new FileInputStream(file), Logger.stream(Level.INFO, this), Logger.stream(Level.WARNING, this) );</pre>SSH, which implements interfaceShell, has only one method,exec. This method accepts four arguments:</p><pre> <p>I think it’s obvious what these arguments are about.</p><p>There are also a few convenient decorators that make it easier to operate with simple commands.</p><h2 id="shellsafe">Shell.Safe</h2><p>interface Shell { int exec( String cmd, InputStream stdin, OutputStream stdout, OutputStream stderr ); }</pre>Shell.Safedecorates an instance ofShelland throws an exception if theexecexit code is not equal to zero. This may be very useful when you want to make sure that your command executed successfully, but don’t want to duplicateif/throwin many places of your code.</p><pre> <h2 id="shellverbose">Shell.Verbose</h2><p>Shell ssh = new Shell.Safe( new SSH( "ssh.example.com", 22, "yegor", "-----BEGIN RSA PRIVATE KEY-----..." ) );</pre>Shell.Verbosedecorates an instance ofShelland copiesstdoutandstderrto the slf4j logging facility (usingjcabi-log). Of course, you can combine decorators, for example:</p><pre> <h2 id="shellplain">Shell.Plain</h2><p>Shell ssh = new Shell.Verbose( new Shell.Safe( new SSH( "ssh.example.com", 22, "yegor", "-----BEGIN RSA PRIVATE KEY-----..." ) ) );</pre>Shell.Plainis a wrapper ofShellthat introduces a newexecmethod with only one argument, a command to execute. It also doesn’t return an exit code, butstdoutinstead. This should be very convenient when you want to execute a simple command and just get its output (I’m combining it withShell.Safefor safety):</p><pre> <h2 id="download">Download</h2><p>You need a single dependencyString login = new Shell.Plain(new Shell.Safe(ssh)).exec("whoami");</pre>jcabi-ssh.jarin your Maven project (get its latest version in Maven Central):</p><pre> <p>The project is in GitHub. If you have any problems, just submit an issue. I’ll try to help.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>An execution of a shell command via SSH can be done in Java, in just a few lines, using<dependency> <groupId>com.jcabi</groupId> <artifactId>jcabi-ssh</artifactId> </dependency></pre>jcabi-ssh:</p><pre> <p>String hello = new Shell.Plain( new SSH( "ssh.example.com", 22, "yegor", "-----BEGIN RSA PRIVATE KEY-----..." ) ).exec("echo 'Hello, world!'");</pre>jcabi-sshis a convenient wrapper ofJSch, a well-known pure Java implementation of SSH2.</p><p>Here is a more complex scenario, where I upload a file via SSH and then read back its grepped content:</p><pre> <p>ClassShell shell = new SSH( "ssh.example.com", 22, "yegor", "-----BEGIN RSA PRIVATE KEY-----..." ); File file = new File("/tmp/data.txt"); new Shell.Safe(shell).exec( "cat > d.txt && grep 'some text' d.txt", new FileInputStream(file), Logger.stream(Level.INFO, this), Logger.stream(Level.WARNING, this) );</pre>SSH, which implements interfaceShell, has only one method,exec. This method accepts four arguments:</p><pre> <p>I think it’s obvious what these arguments are about.</p><p>There are also a few convenient decorators that make it easier to operate with simple commands.</p><h2 id="shellsafe">Shell.Safe</h2><p>interface Shell { int exec( String cmd, InputStream stdin, OutputStream stdout, OutputStream stderr ); }</pre>Shell.Safedecorates an instance ofShelland throws an exception if theexecexit code is not equal to zero. This may be very useful when you want to make sure that your command executed successfully, but don’t want to duplicateif/throwin many places of your code.</p><pre> <h2 id="shellverbose">Shell.Verbose</h2><p>Shell ssh = new Shell.Safe( new SSH( "ssh.example.com", 22, "yegor", "-----BEGIN RSA PRIVATE KEY-----..." ) );</pre>Shell.Verbosedecorates an instance ofShelland copiesstdoutandstderrto the slf4j logging facility (usingjcabi-log). Of course, you can combine decorators, for example:</p><pre> <h2 id="shellplain">Shell.Plain</h2><p>Shell ssh = new Shell.Verbose( new Shell.Safe( new SSH( "ssh.example.com", 22, "yegor", "-----BEGIN RSA PRIVATE KEY-----..." ) ) );</pre>Shell.Plainis a wrapper ofShellthat introduces a newexecmethod with only one argument, a command to execute. It also doesn’t return an exit code, butstdoutinstead. This should be very convenient when you want to execute a simple command and just get its output (I’m combining it withShell.Safefor safety):</p><pre> <h2 id="download">Download</h2><p>You need a single dependencyString login = new Shell.Plain(new Shell.Safe(ssh)).exec("whoami");</pre>jcabi-ssh.jarin your Maven project (get its latest version in Maven Central):</p><pre> <p>The project is in GitHub. If you have any problems, just submit an issue. I’ll try to help.</p></div></article></div><div class="wrapper"><dependency> <groupId>com.jcabi</groupId> <artifactId>jcabi-ssh</artifactId> </dependency></pre></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> How to Release to Maven Central, in One Click </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/08/19/how-to-release-to-maven-central.html>12 Best</li> <li /2014/08/19/how-to-release-to-maven-central.html>All 292</li> <li /2014/08/19/how-to-release-to-maven-central.html>Webinars</li> <li /2014/08/19/how-to-release-to-maven-central.html>Talks</li> <li /2014/08/19/how-to-release-to-maven-central.html>Books</li> <li /2014/08/19/how-to-release-to-maven-central.html>Papers</li> <li /2014/08/19/how-to-release-to-maven-central.html>Pets</li> <li /2014/08/19/how-to-release-to-maven-central.html class=”highlighted”>Trainings</li> <li /2014/08/19/how-to-release-to-maven-central.html>Award</li> <li /2014/08/19/how-to-release-to-maven-central.html>Testimonials</li> <li /2014/08/19/how-to-release-to-maven-central.html>Shift-M</li> <li /2014/08/19/how-to-release-to-maven-central.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/08/19/how-to-release-to-maven-central.html</p><h1 itemprop="name headline mainEntityOfPage">How to Release to Maven Central, in One Click</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>When I release a new version of jcabi-aspects, a Java open source library, to Maven Central, it takes 30 seconds of my time. Maybe even less. Recently, I released version 0.17.2. You can see how it all happened, in GitHub issue #80:</p>
<div class="play"></div></div><div>Cactoos 0.12 polishing and releasing (webinar #27); 2 August 2017.</div></aside><p>Make sure your pom.xmlcontains all elements required by Sonatype, explained in Central Sync Requirements. We will deploy to Sonatype, and they will synchronize all JAR (and not only) artifacts to Maven Central.</p><h2 id="register-a-project-with-sonatype">Register a Project With Sonatype</h2><p>Create an account in Sonatype JIRA and raise a ticket, asking to approve yourgroupId. This OSSRH Guide explains this step in more detail.</p><h2 id="create-and-distribute-a-gpg-key">Create and Distribute a GPG Key</h2><p>Create a GPG key and distribute it, as explained in this Working with PGP Signatures article.</p><p>When this step is done, you should have two files:pubring.gpgandsecring.gpg.</p><h2 id="create-settingsxml">Create settings.xml</h2><p>Createsettings.xml, next to the two.gpgfiles created in the previous step:</p><pre> <p>In this example,<settings> <profiles> <profile> <id>foo</id> <!-- give it the name of your project --> <properties> <gpg.homedir>/home/r</gpg.homedir> <gpg.keyname>9A105525</gpg.keyname> <gpg.passphrase>my-secret</gpg.passphrase> </properties> </profile> </profiles> <servers> <server> <id>oss.sonatype.org</id> <username><!-- Sonatype JIRA user name --></username> <password><!-- Sonatype JIRA pwd --></password> </server> </servers> </settings></pre>9A105525is the ID of your public key, andmy-secretis the pass phrase you have used while generating the keys.</p><h2 id="encrypt-security-assets">Encrypt Security Assets</h2><p>Now, encrypt these three files with a rultor remote:</p><pre> <p>Instead of$ gem install rultor $ rultor encrypt -p me/test pubring.gpg $ rultor encrypt -p me/test secring.gpg $ rultor encrypt -p me/test settings.xml</pre>me/testyou should use the name of your GitHub project.</p><p>You will get three new files:pubring.gpg.asc,secring.gpg.ascandsettings.xml.asc. Add them to the root directory of your project, commit and push. The files contain your secret information, but only the Rultor server can decrypt them.</p><h2 id="add-sonatype-repositories">Add Sonatype Repositories</h2><p>I would recommend using jcabi-parent, as a parent pom for your project. This will make many further steps unnecessary. If you’re using jcabi-parent, skip this step.</p><p>However, if you don’t use jcabi-parent, you should add these two repositories to yourpom.xml:</p><pre> <h2 id="configure-gpg-plugin">Configure GPG Plugin</h2><p>Again, I’d recommend using jcabi-parent, which configures this plugin automatically. If you’re using it, skip this step.</p><p>Otherwise, add this plugin to your<project> [...] <distributionManagement> <repository> <id>oss.sonatype.org</id> <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url> </repository> <snapshotRepository> <id>oss.sonatype.org</id> <url>https://oss.sonatype.org/content/repositories/snapshots</url> </snapshotRepository> </distributionManagement> </project></pre>pom.xml:</p><pre> <h2 id="configure-versions-plugin">Configure Versions Plugin</h2><p>Once again, I recommend using http://parent.jcabi.com. It configures all required plugins out-of-the-box. If you’re using it, skip this step.</p><p>Otherwise, add this plugin to your<project> [..] <build> [..] <plugins> [..] <plugin> <artifactId>maven-gpg-plugin</artifactId> <version>1.5</version> <executions> <execution> <id>sign-artifacts</id> <phase>verify</phase> <goals> <goal>sign</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project></pre>pom.xml:</p><pre> <h2 id="configure-sonatype-plugin">Configure Sonatype Plugin</h2><p>Yes, you’re right, http://parent.jcabi.com will help you here as well. If you’re using it, skip this step too.</p><p>Otherwise, add these four plugins to your<project> [..] <build> [..] <plugins> [..] <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>versions-maven-plugin</artifactId> <version>2.1</version> <configuration> <generateBackupPoms>false</generateBackupPoms> </configuration> </plugin> </plugins> </build> </project></pre>pom.xml:</p><pre> <h2 id="create-rultor-configuration">Create Rultor Configuration</h2><p>Create a<project> [..] <build> [..] <plugins> [..] <plugin> <artifactId>maven-deploy-plugin</artifactId> <configuration> <skip>true</skip> </configuration> </plugin> <plugin> <artifactId>maven-source-plugin</artifactId> <executions> <execution> <id>package-sources</id> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> <plugin> <artifactId>maven-javadoc-plugin</artifactId> <executions> <execution> <id>package-javadoc</id> <phase>package</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.sonatype.plugins</groupId> <artifactId>nexus-staging-maven-plugin</artifactId> <version>1.6</version> <extensions>true</extensions> <configuration> <serverId>oss.sonatype.org</serverId> <nexusUrl>https://oss.sonatype.org/</nexusUrl> <description>${project.version}</description> </configuration> <executions> <execution> <id>deploy-to-sonatype</id> <phase>deploy</phase> <goals> <goal>deploy</goal> <goal>release</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project></pre>.rultor.ymlfile in the root directory of your project (reference page explains this format in details):</p><pre> <p>You can compare your file with live Rultor configuration of jcabi-aspects.</p><h2 id="run-it">Run It!</h2>decrypt: settings.xml: "repo/settings.xml.asc" pubring.gpg: "repo/pubring.gpg.asc" secring.gpg: "repo/secring.gpg.asc" release: script: | mvn versions:set "-DnewVersion=${tag}" git commit -am "${tag}" mvn clean deploy -Pjcabi --settings /home/r/settings.xml</pre><pre> <p>You will get a response in a few seconds. The rest will be done by Rultor.</p><p>Enjoy :)</p><p>BTW, if something doesn’t work as I’ve explained, don’t hesitate to submit a ticket to Rultor issue tracker. I will try to help you.</p><p>Yeah, forgot to mention, Rultor is also doing two important things. First, it creates a GitHub release with a proper description. Second, it posts a tweet about the release, which you can retweet, to make an announcement to your followers. Both features are very convenient for me. For example:</p><blockquote class="twitter-tweet" lang="en"><p>DynamoDB Local Maven Plugin, 0.7.1 released https://t.co/C3KULouuKS</p>—rultor.com (@rultors) August 19, 2014</blockquote> </p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>When I release a new version of jcabi-aspects, a Java open source library, to Maven Central, it takes 30 seconds of my time. Maybe even less. Recently, I released version 0.17.2. You can see how it all happened, in GitHub issue #80:</p>@rultor release, tag is `0.1`</pre>pom.xmlcontains all elements required by Sonatype, explained in Central Sync Requirements. We will deploy to Sonatype, and they will synchronize all JAR (and not only) artifacts to Maven Central.</p><h2 id="register-a-project-with-sonatype">Register a Project With Sonatype</h2><p>Create an account in Sonatype JIRA and raise a ticket, asking to approve yourgroupId. This OSSRH Guide explains this step in more detail.</p><h2 id="create-and-distribute-a-gpg-key">Create and Distribute a GPG Key</h2><p>Create a GPG key and distribute it, as explained in this Working with PGP Signatures article.</p><p>When this step is done, you should have two files:pubring.gpgandsecring.gpg.</p><h2 id="create-settingsxml">Create settings.xml</h2><p>Createsettings.xml, next to the two.gpgfiles created in the previous step:</p><pre> <p>In this example,<settings> <profiles> <profile> <id>foo</id> <!-- give it the name of your project --> <properties> <gpg.homedir>/home/r</gpg.homedir> <gpg.keyname>9A105525</gpg.keyname> <gpg.passphrase>my-secret</gpg.passphrase> </properties> </profile> </profiles> <servers> <server> <id>oss.sonatype.org</id> <username><!-- Sonatype JIRA user name --></username> <password><!-- Sonatype JIRA pwd --></password> </server> </servers> </settings></pre>9A105525is the ID of your public key, andmy-secretis the pass phrase you have used while generating the keys.</p><h2 id="encrypt-security-assets">Encrypt Security Assets</h2><p>Now, encrypt these three files with a rultor remote:</p><pre> <p>Instead of$ gem install rultor $ rultor encrypt -p me/test pubring.gpg $ rultor encrypt -p me/test secring.gpg $ rultor encrypt -p me/test settings.xml</pre>me/testyou should use the name of your GitHub project.</p><p>You will get three new files:pubring.gpg.asc,secring.gpg.ascandsettings.xml.asc. Add them to the root directory of your project, commit and push. The files contain your secret information, but only the Rultor server can decrypt them.</p><h2 id="add-sonatype-repositories">Add Sonatype Repositories</h2><p>I would recommend using jcabi-parent, as a parent pom for your project. This will make many further steps unnecessary. If you’re using jcabi-parent, skip this step.</p><p>However, if you don’t use jcabi-parent, you should add these two repositories to yourpom.xml:</p><pre> <h2 id="configure-gpg-plugin">Configure GPG Plugin</h2><p>Again, I’d recommend using jcabi-parent, which configures this plugin automatically. If you’re using it, skip this step.</p><p>Otherwise, add this plugin to your<project> [...] <distributionManagement> <repository> <id>oss.sonatype.org</id> <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url> </repository> <snapshotRepository> <id>oss.sonatype.org</id> <url>https://oss.sonatype.org/content/repositories/snapshots</url> </snapshotRepository> </distributionManagement> </project></pre>pom.xml:</p><pre> <h2 id="configure-versions-plugin">Configure Versions Plugin</h2><p>Once again, I recommend using http://parent.jcabi.com. It configures all required plugins out-of-the-box. If you’re using it, skip this step.</p><p>Otherwise, add this plugin to your<project> [..] <build> [..] <plugins> [..] <plugin> <artifactId>maven-gpg-plugin</artifactId> <version>1.5</version> <executions> <execution> <id>sign-artifacts</id> <phase>verify</phase> <goals> <goal>sign</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project></pre>pom.xml:</p><pre> <h2 id="configure-sonatype-plugin">Configure Sonatype Plugin</h2><p>Yes, you’re right, http://parent.jcabi.com will help you here as well. If you’re using it, skip this step too.</p><p>Otherwise, add these four plugins to your<project> [..] <build> [..] <plugins> [..] <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>versions-maven-plugin</artifactId> <version>2.1</version> <configuration> <generateBackupPoms>false</generateBackupPoms> </configuration> </plugin> </plugins> </build> </project></pre>pom.xml:</p><pre> <h2 id="create-rultor-configuration">Create Rultor Configuration</h2><p>Create a<project> [..] <build> [..] <plugins> [..] <plugin> <artifactId>maven-deploy-plugin</artifactId> <configuration> <skip>true</skip> </configuration> </plugin> <plugin> <artifactId>maven-source-plugin</artifactId> <executions> <execution> <id>package-sources</id> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> <plugin> <artifactId>maven-javadoc-plugin</artifactId> <executions> <execution> <id>package-javadoc</id> <phase>package</phase> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.sonatype.plugins</groupId> <artifactId>nexus-staging-maven-plugin</artifactId> <version>1.6</version> <extensions>true</extensions> <configuration> <serverId>oss.sonatype.org</serverId> <nexusUrl>https://oss.sonatype.org/</nexusUrl> <description>${project.version}</description> </configuration> <executions> <execution> <id>deploy-to-sonatype</id> <phase>deploy</phase> <goals> <goal>deploy</goal> <goal>release</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project></pre>.rultor.ymlfile in the root directory of your project (reference page explains this format in details):</p><pre> <p>You can compare your file with live Rultor configuration of jcabi-aspects.</p><h2 id="run-it">Run It!</h2>decrypt: settings.xml: "repo/settings.xml.asc" pubring.gpg: "repo/pubring.gpg.asc" secring.gpg: "repo/secring.gpg.asc" release: script: | mvn versions:set "-DnewVersion=${tag}" git commit -am "${tag}" mvn clean deploy -Pjcabi --settings /home/r/settings.xml</pre><pre> <p>You will get a response in a few seconds. The rest will be done by Rultor.</p><p>Enjoy :)</p><p>BTW, if something doesn’t work as I’ve explained, don’t hesitate to submit a ticket to Rultor issue tracker. I will try to help you.</p><p>Yeah, forgot to mention, Rultor is also doing two important things. First, it creates a GitHub release with a proper description. Second, it posts a tweet about the release, which you can retweet, to make an announcement to your followers. Both features are very convenient for me. For example:</p><blockquote class="twitter-tweet" lang="en"><p>DynamoDB Local Maven Plugin, 0.7.1 released https://t.co/C3KULouuKS</p>—rultor.com (@rultors) August 19, 2014</blockquote> </div></article></div><div class="wrapper">@rultor release, tag is `0.1`</pre></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Objects Should Be Immutable </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/06/09/objects-should-be-immutable.html>12 Best</li> <li /2014/06/09/objects-should-be-immutable.html>All 292</li> <li /2014/06/09/objects-should-be-immutable.html>Webinars</li> <li /2014/06/09/objects-should-be-immutable.html>Talks</li> <li /2014/06/09/objects-should-be-immutable.html>Books</li> <li /2014/06/09/objects-should-be-immutable.html>Papers</li> <li /2014/06/09/objects-should-be-immutable.html>Pets</li> <li /2014/06/09/objects-should-be-immutable.html class=”highlighted”>Trainings</li> <li /2014/06/09/objects-should-be-immutable.html>Award</li> <li /2014/06/09/objects-should-be-immutable.html>Testimonials</li> <li /2014/06/09/objects-should-be-immutable.html>Shift-M</li> <li /2014/06/09/objects-should-be-immutable.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/06/09/objects-should-be-immutable.html</p><h1 itemprop="name headline mainEntityOfPage">Objects Should Be Immutable</h1><aside class='book'>Read more about this subject in Section 2.6
of my book</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="subline"> <li>Discussed at:</li> <li>reddit</li></ul><p class="unprintable"><p>In object-oriented programming, an object is immutable if its state can’t be modified after it is created. In Java, a good example of an immutable object is String. Once created, we can’t modify its state. We can request that it creates new strings, but its own state will never change.</p><p>However, there are not so many immutable classes in JDK. Take, for example, classDate. It is possible to modify its state usingsetTime().</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Immutable Objects vs. Common Sense (webinar #2); 6 May 2015.</div></aside><p>I don’t know why the JDK designers decided to make these two very similar classes differently. However, I believe that the design of a mutable Datehas many flaws, while the immutableStringis much more in the spirit of the object-oriented paradigm.</p><p>Moreover, I think that all classes should be immutable in a perfect object-oriented world. Unfortunately, sometimes, it is technically not possible due to limitations in JVM. Nevertheless, we should always aim for the best.</p><p>This is an incomplete list of arguments in favor of immutability:</p><ul> <li>immutable objects are simpler to construct, test, and use</li> <li>truly immutable objects are always thread-safe</li> <li>they help to avoid temporal coupling</li> <li>their usage is side-effect free (no defensive copies)</li> <li>identity mutability problem is avoided</li> <li>they always have failure atomicity</li> <li>they are much easier to cache</li> <li>they prevent NULL references, which are bad</li></ul><p>Let’s discuss the most important arguments one by one.</p><h2 id="thread-safety">Thread Safety</h2><p>The first and the most obvious argument is that immutable objects are thread-safe. This means that multiple threads can access the same object at the same time, without clashing with another thread.</p>
<pre> <p>This code works. However, you must remember that the first request should be configured before the second one may happen. If we decide to remove the first request from the script, we will remove the second and the third line, and won’t get any errors from the compiler:</p>Request request = new Request("http://localhost"); request.method("POST"); String first = request.fetch(); request.body("text=hello"); String second = request.fetch();</pre><pre> <p>Now, the script is broken although it compiled without errors. This is what temporal coupling is about—there is always some hidden information in the code that a programmer has to remember. In this example, we have to remember that the configuration for the first request is also used for the second one.</p><aside class="youtube"> <div class="box">Request request = new Request("http://localhost"); // request.method("POST"); // String first = request.fetch(); request.body("text=hello"); String second = request.fetch();</pre><div class="play"></div></div><div>How Immutability Helps in OOP (in Russian with English subtitles); 21 May 2016.</div></aside><p>We have to remember that the second request should always stay together and be executed after the first one.</p><p>If Requestclass were immutable, the first snippet wouldn’t work in the first place, and would have been rewritten like:</p><pre> <p>Now, these two requests are not coupled. We can safely remove the first one, and the second one will still work correctly. You may point out that there is a code duplication. Yes, we should get rid of it and re-write the code:</p>final Request request = new Request(""); String first = request.method("POST").fetch(); String second = request.method("POST").body("text=hello").fetch();</pre><pre> <p>See, refactoring didn’t break anything and we still don’t have temporal coupling. The first request can be removed safely from the code without affecting the second one.</p><p>I hope this example demonstrates that the code manipulating immutable objects is more readable and maintainable, because it doesn’t have temporal coupling.</p><h2 id="avoiding-side-effects">Avoiding Side Effects</h2><p>Let’s try to use ourfinal Request request = new Request(""); final Request post = request.method("POST"); String first = post.fetch(); String second = post.body("text=hello").fetch();</pre>Requestclass in a new method (now it is mutable):</p><pre> <p>Let’s try to make two requests—the first with GET method and the second with POST:</p>public String post(Request request) { request.method("POST"); return request.fetch(); }</pre><pre> <p>MethodRequest request = new Request("http://localhost"); request.method("GET"); String first = this.post(request); String second = request.fetch();</pre>post()has a “side effect”—it makes changes to the mutable objectrequest. These changes are not really expected in this case. We expect it to make a POST request and return its body. We don’t want to read its documentation just to find out that behind the scene it also modifies the request we’re passing to it as an argument.</p><p>Needless to say, such side effects lead to bugs and maintainability issues. It would be much better to work with an immutableRequest:</p><pre> <p>In this case, we may not have any side effects. Nobody can modify ourpublic String post(Request request) { return request.method("POST").fetch(); }</pre>requestobject, no matter where it is used and how deep through the call stack it is passed by method calls:</p><pre> <p>This code is perfectly safe and side effect free.</p><h2 id="avoiding-identity-mutability">Avoiding Identity Mutability</h2><p>Very often, we want objects to be identical if their internal states are the same.Request request = new Request("http://localhost").method("GET"); String first = this.post(request); String second = request.fetch();</pre>Dateclass is a good example:</p><pre> <p>There are two different objects; however, they are equal to each other because their encapsulated states are the same. This is made possible through their custom overloaded implementation ofDate first = new Date(1L); Date second = new Date(1L); assert first.equals(second); // true</pre>equals()andhashCode()methods.</p><p>The consequence of this convenient approach being used with mutable objects is that every time we modify object’s state it changes its identity:</p><pre> <p>This may look natural, until you start using your mutable objects as keys in maps:</p>Date first = new Date(1L); Date second = new Date(1L); first.setTime(2L); assert first.equals(second); // false</pre><pre> <p>When modifying the state ofMap<Date, String> map = new HashMap<>(); Date date = new Date(); map.put(date, "hello, world!"); date.setTime(12345L); assert map.containsKey(date); // false</pre>dateobject, we’re not expecting it to change its identity. We’re not expecting to lose an entry in the map just because the state of its key is changed. However, this is exactly what is happening in the example above.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>How Much Immutability Is Enough?; 19 May 2016.</div></aside><p>When we add an object to the map, its hashCode()returns one value. This value is used byHashMapto place the entry into the internal hash table. When we callcontainsKey()hash code of the object is different (because it is based on its internal state) andHashMapcan’t find it in the internal hash table.</p><p>It is a very annoying and difficult to debug side effects of mutable objects. Immutable objects avoid it completely.</p><h2 id="failure-atomicity">Failure Atomicity</h2><p>Here is a simple example:</p><pre> <p>It is obvious that an object of classpublic class Stack { private int size; private String[] items; public void push(String item) { size++; if (size > items.length) { throw new RuntimeException("stack overflow"); } items[size] = item; } }</pre>Stackwill be left in a broken state if it throws a runtime exception on overflow. Itssizeproperty will be incremented, whileitemswon’t get a new element.</p>
jcabi-http,jcabi-xml,jcabi-github,jcabi-s3,jcabi-dynamo,jcabi-w3c,jcabi-jdbc,jcabi-simpledb,jcabi-ssh. The above are all Java libraries that work solely with immutable classes/objects. netbout.com and stateful.co are web applications that work solely with immutable objects.</p></li> <li><p>“It’s cheaper to update an existing object than create a new one”. Oracle thinks that “The impact of object creation is often overestimated and can be offset by some of the efficiency associated with immutable objects. These include decreased overhead due to garbage collection, and the elimination of code needed to protect mutable objects from corruption.” I agree.</p></li> </ol><p>If you have some other arguments, please post them below and I’ll try to comment.</p><p>P.S. Check takes.org, a Java web framework that consists entirely of immutable objects.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>In object-oriented programming, an object is immutable if its state can’t be modified after it is created. In Java, a good example of an immutable object isString. Once created, we can’t modify its state. We can request that it creates new strings, but its own state will never change.</p><p>However, there are not so many immutable classes in JDK. Take, for example, classDate. It is possible to modify its state usingsetTime().</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Immutable Objects vs. Common Sense (webinar #2); 6 May 2015.</div></aside><p>I don’t know why the JDK designers decided to make these two very similar classes differently. However, I believe that the design of a mutable Datehas many flaws, while the immutableStringis much more in the spirit of the object-oriented paradigm.</p><p>Moreover, I think that all classes should be immutable in a perfect object-oriented world. Unfortunately, sometimes, it is technically not possible due to limitations in JVM. Nevertheless, we should always aim for the best.</p><p>This is an incomplete list of arguments in favor of immutability:</p><ul> <li>immutable objects are simpler to construct, test, and use</li> <li>truly immutable objects are always thread-safe</li> <li>they help to avoid temporal coupling</li> <li>their usage is side-effect free (no defensive copies)</li> <li>identity mutability problem is avoided</li> <li>they always have failure atomicity</li> <li>they are much easier to cache</li> <li>they prevent NULL references, which are bad</li></ul><p>Let’s discuss the most important arguments one by one.</p><h2 id="thread-safety">Thread Safety</h2><p>The first and the most obvious argument is that immutable objects are thread-safe. This means that multiple threads can access the same object at the same time, without clashing with another thread.</p><pre> <p>This code works. However, you must remember that the first request should be configured before the second one may happen. If we decide to remove the first request from the script, we will remove the second and the third line, and won’t get any errors from the compiler:</p>Request request = new Request("http://localhost"); request.method("POST"); String first = request.fetch(); request.body("text=hello"); String second = request.fetch();</pre><pre> <p>Now, the script is broken although it compiled without errors. This is what temporal coupling is about—there is always some hidden information in the code that a programmer has to remember. In this example, we have to remember that the configuration for the first request is also used for the second one.</p><aside class="youtube"> <div class="box">Request request = new Request("http://localhost"); // request.method("POST"); // String first = request.fetch(); request.body("text=hello"); String second = request.fetch();</pre><div class="play"></div></div><div>How Immutability Helps in OOP (in Russian with English subtitles); 21 May 2016.</div></aside><p>We have to remember that the second request should always stay together and be executed after the first one.</p><p>If Requestclass were immutable, the first snippet wouldn’t work in the first place, and would have been rewritten like:</p><pre> <p>Now, these two requests are not coupled. We can safely remove the first one, and the second one will still work correctly. You may point out that there is a code duplication. Yes, we should get rid of it and re-write the code:</p>final Request request = new Request(""); String first = request.method("POST").fetch(); String second = request.method("POST").body("text=hello").fetch();</pre><pre> <p>See, refactoring didn’t break anything and we still don’t have temporal coupling. The first request can be removed safely from the code without affecting the second one.</p><p>I hope this example demonstrates that the code manipulating immutable objects is more readable and maintainable, because it doesn’t have temporal coupling.</p><h2 id="avoiding-side-effects">Avoiding Side Effects</h2><p>Let’s try to use ourfinal Request request = new Request(""); final Request post = request.method("POST"); String first = post.fetch(); String second = post.body("text=hello").fetch();</pre>Requestclass in a new method (now it is mutable):</p><pre> <p>Let’s try to make two requests—the first with GET method and the second with POST:</p>public String post(Request request) { request.method("POST"); return request.fetch(); }</pre><pre> <p>MethodRequest request = new Request("http://localhost"); request.method("GET"); String first = this.post(request); String second = request.fetch();</pre>post()has a “side effect”—it makes changes to the mutable objectrequest. These changes are not really expected in this case. We expect it to make a POST request and return its body. We don’t want to read its documentation just to find out that behind the scene it also modifies the request we’re passing to it as an argument.</p><p>Needless to say, such side effects lead to bugs and maintainability issues. It would be much better to work with an immutableRequest:</p><pre> <p>In this case, we may not have any side effects. Nobody can modify ourpublic String post(Request request) { return request.method("POST").fetch(); }</pre>requestobject, no matter where it is used and how deep through the call stack it is passed by method calls:</p><pre> <p>This code is perfectly safe and side effect free.</p><h2 id="avoiding-identity-mutability">Avoiding Identity Mutability</h2><p>Very often, we want objects to be identical if their internal states are the same.Request request = new Request("http://localhost").method("GET"); String first = this.post(request); String second = request.fetch();</pre>Dateclass is a good example:</p><pre> <p>There are two different objects; however, they are equal to each other because their encapsulated states are the same. This is made possible through their custom overloaded implementation ofDate first = new Date(1L); Date second = new Date(1L); assert first.equals(second); // true</pre>equals()andhashCode()methods.</p><p>The consequence of this convenient approach being used with mutable objects is that every time we modify object’s state it changes its identity:</p><pre> <p>This may look natural, until you start using your mutable objects as keys in maps:</p>Date first = new Date(1L); Date second = new Date(1L); first.setTime(2L); assert first.equals(second); // false</pre><pre> <p>When modifying the state ofMap<Date, String> map = new HashMap<>(); Date date = new Date(); map.put(date, "hello, world!"); date.setTime(12345L); assert map.containsKey(date); // false</pre>dateobject, we’re not expecting it to change its identity. We’re not expecting to lose an entry in the map just because the state of its key is changed. However, this is exactly what is happening in the example above.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>How Much Immutability Is Enough?; 19 May 2016.</div></aside><p>When we add an object to the map, its hashCode()returns one value. This value is used byHashMapto place the entry into the internal hash table. When we callcontainsKey()hash code of the object is different (because it is based on its internal state) andHashMapcan’t find it in the internal hash table.</p><p>It is a very annoying and difficult to debug side effects of mutable objects. Immutable objects avoid it completely.</p><h2 id="failure-atomicity">Failure Atomicity</h2><p>Here is a simple example:</p><pre> <p>It is obvious that an object of classpublic class Stack { private int size; private String[] items; public void push(String item) { size++; if (size > items.length) { throw new RuntimeException("stack overflow"); } items[size] = item; } }</pre>Stackwill be left in a broken state if it throws a runtime exception on overflow. Itssizeproperty will be incremented, whileitemswon’t get a new element.</p>jcabi-http,jcabi-xml,jcabi-github,jcabi-s3,jcabi-dynamo,jcabi-w3c,jcabi-jdbc,jcabi-simpledb,jcabi-ssh. The above are all Java libraries that work solely with immutable classes/objects. netbout.com and stateful.co are web applications that work solely with immutable objects.</p></li> <li><p>“It’s cheaper to update an existing object than create a new one”. Oracle thinks that “The impact of object creation is often overestimated and can be offset by some of the efficiency associated with immutable objects. These include decreased overhead due to garbage collection, and the elimination of code needed to protect mutable objects from corruption.” I agree.</p></li> </ol><p>If you have some other arguments, please post them below and I’ll try to comment.</p><p>P.S. Check takes.org, a Java web framework that consists entirely of immutable objects.</p></div></article></div><div class="wrapper"><div class="unprintable"> <hr/><p>If you like this article, you will definitely like these very relevant posts too:</p><p>Immutable Objects Are Not Dumb
Immutable objects are not the same as passive data structures without setters, despite a very common mis-belief.</p><p>How an Immutable Object Can Have State and Behavior?
Object state and behavior are two very different things, and confusing the two often leads to incorrect design.</p><p>Gradients of Immutability
There are a few levels and forms of immutability in object-oriented programming, all of which can be used when they seem appropriate.</p></div></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;">Java Method Logging with AOP and Annotations </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>12 Best</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>All 292</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Webinars</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Talks</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Books</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Papers</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Pets</li> <li /2014/06/01/aop-aspectj-java-method-logging.html class=”highlighted”>Trainings</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Award</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Testimonials</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Shift-M</li> <li /2014/06/01/aop-aspectj-java-method-logging.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/06/01/aop-aspectj-java-method-logging.html</p><h1 itemprop="name headline mainEntityOfPage">Java Method Logging with AOP and Annotations</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable"><p>Sometimes, I want to log (through slf4j and log4j) every execution of a method, seeing what arguments it receives, what it returns and how much time every execution takes. This is how I’m doing it, with help of AspectJ, jcabi-aspects and Java 6 annotations:</p><pre> <p>This is what I see in log4j output:</p>public class Foo { @Loggable public int power(int x, int p) { return Math.pow(x, p); } }</pre><pre> <p>Nice, isn’t it? Now, let’s see how it works.</p><h2 id="annotation-with-runtime-retention">Annotation with Runtime Retention</h2><p>Annotations is a technique introduced in Java 6. It is a meta-programming instrument that doesn’t change the way code works, but gives marks to certain elements (methods, classes or variables). In other words, annotations are just markers attached to the code that can be seen and read. Some annotations are designed to be seen at compile time only—they don’t exist in[INFO] com.example.Foo #power(2, 10): 1024 in 12μs [INFO] com.example.Foo #power(3, 3): 27 in 4μs</pre>.classfiles after compilation. Others remain visible after compilation and can be accessed in runtime.</p><aside class="youtube"> <div class="box">
<div class="play"></div></div><div>Practical Example of AOP with AspectJ (in Russian with English subtitles); 28 October 2016.</div></aside><p>For example, @Overrideis of the first type (its retention type isSOURCE), while@Testfrom JUnit is of the second type (retention type isRUNTIME).@Loggable—the one I’m using in the script above—is an annotation of the second type, from jcabi-aspects. It stays with the byte-code in the.classfile after compilation.</p><p>Again, it is important to understand that even though methodpower()is annotated and compiled, it doesn’t send anything to slf4j so far. It just contains a marker saying “please, log my execution.”</p><h2 id="aspect-oriented-programming-aop">Aspect Oriented Programming (AOP)</h2><p>AOP is a useful technique that enables adding executable blocks to the source code without explicitly changing it. In our example, we don’t want to log method execution inside the class. Instead, we want some other class to intercept every call to methodpower(), measure its execution time and send this information to slf4j.</p><p>We want that interceptor to understand our@Loggableannotation and log every call to that specific methodpower(). And, of course, the same interceptor should be used for other methods where we’ll place the same annotation in the future.</p><p>This case perfectly fits the original intent of AOP—to avoid re-implementation of some common behavior in multiple classes.</p><p>Logging is a supplementary feature to our main functionality, and we don’t want to pollute our code with multiple logging instructions. Instead, we want logging to happen behind the scenes.</p><p>In terms of AOP, our solution can be explained as creating an aspect that cross-cuts the code at certain join points and applies an around advice that implements the desired functionality.</p><h2 id="aspectj">AspectJ</h2><p>Let’s see what these magic words mean. But, first, let’s see how jcabi-aspects implements them using AspectJ (it’s a simplified example, full code you can find inMethodLogger.java):</p><pre> <p>This is an aspect with a single around advice@Aspect public class MethodLogger { @Around("execution(* *(..)) && @annotation(Loggable)") public Object around(ProceedingJoinPoint point) { long start = System.currentTimeMillis(); Object result = point.proceed(); Logger.info( "#%s(%s): %s in %[msec]s", MethodSignature.class.cast(point.getSignature()).getMethod().getName(), point.getArgs(), result, System.currentTimeMillis() - start ); return result; } }</pre>around()inside. The aspect is annotated with@Aspectand advice is annotated with@Around. As discussed above, these annotations are just markers in.classfiles. They don’t do anything except provide some meta-information to those who are interested in runtime.</p><p>Annotation@Aroundhas one parameter, which—in this case—says that the advice should be applied to a method if:</p><ol> <li><p>its visibility modifier is*(public,protectedorprivate);</p></li> <li><p>its name is name*(any name);</p></li> <li><p>its arguments are..(any arguments); and</p></li> <li><p>it is annotated with@Loggable</p></li> </ol><p>When a call to an annotated method is to be intercepted, methodaround()executes before executing the actual method. When a call to methodpower()is to be intercepted, methodaround()receives an instance of classProceedingJoinPointand must return an object, which will be used as a result of methodpower().</p><p>In order to call the original method,power(), the advice has to callproceed()of the join point object.</p><p>We compile this aspect and make it available in classpath together with our main fileFoo.class. So far so good, but we need to take one last step in order to put our aspect into action—we should apply our advice.</p><h2 id="binary-aspect-weaving">Binary Aspect Weaving</h2><p>Aspect weaving is the name of the advice applying process. Aspect weaver modifies original code by injecting calls to aspects. AspectJ does exactly that. We give it two binary Java classesFoo.classandMethodLogger.class; it gives back three—modifiedFoo.class,Foo$AjcClosure1.classand unmodifiedMethodLogger.class.</p><aside class="quote">Without weaving, both classes and aspects are just compiled Java binaries with attached annotations</aside><p>In order to understand which advice should be applied to which methods, AspectJ weaver is using annotations from.classfiles. Also, it uses reflection to browse all classes on classpath. It analyzes which methods satisfy the conditions from the@Aroundannotation. Of course, it finds our methodpower().</p><p>So, there are two steps. First, we compile our.javafiles usingjavacand get two files. Then, AspectJ weaves/modifies them and creates its own extra class. OurFooclass looks something like this after weaving:</p><pre> <p>AspectJ weaver moves our original functionality to a new method,public class Foo { private final MethodLogger logger; @Loggable public int power(int x, int p) { return this.logger.around(point); } private int power_aroundBody(int x, int p) { return Math.pow(x, p); } }</pre>power_aroundBody(), and redirects allpower()calls to the aspect classMethodLogger.</p><p>Instead of one methodpower()in classFoonow we have four classes working together. From now on, this is what happens behind the scenes on every call topower():</p><p>
</p><p>Original functionality of method power()is indicated by the small green lifeline on the diagram.</p><p>As you see, the aspect weaving process connects together classes and aspects, transferring calls between them through join points. Without weaving, both classes and aspects are just compiled Java binaries with attached annotations.</p><h1 id="jcabi-aspects">jcabi-aspects</h1><p>jcabi-aspects is a JAR library that containsLoggableannotation andMethodLoggeraspect (btw, there are many more aspects and annotations). You don’t need to write your own aspect for method logging. Just add a few dependencies to your classpath and configure jcabi-maven-plugin for aspect weaving (get their latest versions in Maven Central):</p><pre> <p>Since this weaving procedure takes a lot of configuration effort, I created a convenient Maven plugin with an<project> <dependencies> <dependency> <groupId>com.jcabi</groupId> <artifactId>jcabi-aspects</artifactId> </dependency> <dependency> <groupId>org.aspectj</groupId> <artifactId>aspectjrt</artifactId> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>com.jcabi</groupId> <artifactId>jcabi-maven-plugin</artifactId> <executions> <execution> <goals> <goal>ajc</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project></pre>ajcgoal, which does the entire aspect weaving job. You can use AspectJ directly, but I recommend that you use jcabi-maven-plugin.</p><p>That’s it. Now you can use@com.jcabi.aspects.Loggableannotation and your methods will be logged through slf4j.</p><p>If something doesn’t work as explained, don’t hesitate to submit a GitHub issue.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>Sometimes, I want to log (through slf4j and log4j) every execution of a method, seeing what arguments it receives, what it returns and how much time every execution takes. This is how I’m doing it, with help of AspectJ, jcabi-aspects and Java 6 annotations:</p><pre> <p>This is what I see in log4j output:</p>public class Foo { @Loggable public int power(int x, int p) { return Math.pow(x, p); } }</pre><pre> <p>Nice, isn’t it? Now, let’s see how it works.</p><h2 id="annotation-with-runtime-retention">Annotation with Runtime Retention</h2><p>Annotations is a technique introduced in Java 6. It is a meta-programming instrument that doesn’t change the way code works, but gives marks to certain elements (methods, classes or variables). In other words, annotations are just markers attached to the code that can be seen and read. Some annotations are designed to be seen at compile time only—they don’t exist in[INFO] com.example.Foo #power(2, 10): 1024 in 12μs [INFO] com.example.Foo #power(3, 3): 27 in 4μs</pre>.classfiles after compilation. Others remain visible after compilation and can be accessed in runtime.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Practical Example of AOP with AspectJ (in Russian with English subtitles); 28 October 2016.</div></aside><p>For example, @Overrideis of the first type (its retention type isSOURCE), while@Testfrom JUnit is of the second type (retention type isRUNTIME).@Loggable—the one I’m using in the script above—is an annotation of the second type, from jcabi-aspects. It stays with the byte-code in the.classfile after compilation.</p><p>Again, it is important to understand that even though methodpower()is annotated and compiled, it doesn’t send anything to slf4j so far. It just contains a marker saying “please, log my execution.”</p><h2 id="aspect-oriented-programming-aop">Aspect Oriented Programming (AOP)</h2><p>AOP is a useful technique that enables adding executable blocks to the source code without explicitly changing it. In our example, we don’t want to log method execution inside the class. Instead, we want some other class to intercept every call to methodpower(), measure its execution time and send this information to slf4j.</p><p>We want that interceptor to understand our@Loggableannotation and log every call to that specific methodpower(). And, of course, the same interceptor should be used for other methods where we’ll place the same annotation in the future.</p><p>This case perfectly fits the original intent of AOP—to avoid re-implementation of some common behavior in multiple classes.</p><p>Logging is a supplementary feature to our main functionality, and we don’t want to pollute our code with multiple logging instructions. Instead, we want logging to happen behind the scenes.</p><p>In terms of AOP, our solution can be explained as creating an aspect that cross-cuts the code at certain join points and applies an around advice that implements the desired functionality.</p><h2 id="aspectj">AspectJ</h2><p>Let’s see what these magic words mean. But, first, let’s see how jcabi-aspects implements them using AspectJ (it’s a simplified example, full code you can find inMethodLogger.java):</p><pre> <p>This is an aspect with a single around advice@Aspect public class MethodLogger { @Around("execution(* *(..)) && @annotation(Loggable)") public Object around(ProceedingJoinPoint point) { long start = System.currentTimeMillis(); Object result = point.proceed(); Logger.info( "#%s(%s): %s in %[msec]s", MethodSignature.class.cast(point.getSignature()).getMethod().getName(), point.getArgs(), result, System.currentTimeMillis() - start ); return result; } }</pre>around()inside. The aspect is annotated with@Aspectand advice is annotated with@Around. As discussed above, these annotations are just markers in.classfiles. They don’t do anything except provide some meta-information to those who are interested in runtime.</p><p>Annotation@Aroundhas one parameter, which—in this case—says that the advice should be applied to a method if:</p><ol> <li><p>its visibility modifier is*(public,protectedorprivate);</p></li> <li><p>its name is name*(any name);</p></li> <li><p>its arguments are..(any arguments); and</p></li> <li><p>it is annotated with@Loggable</p></li> </ol><p>When a call to an annotated method is to be intercepted, methodaround()executes before executing the actual method. When a call to methodpower()is to be intercepted, methodaround()receives an instance of classProceedingJoinPointand must return an object, which will be used as a result of methodpower().</p><p>In order to call the original method,power(), the advice has to callproceed()of the join point object.</p><p>We compile this aspect and make it available in classpath together with our main fileFoo.class. So far so good, but we need to take one last step in order to put our aspect into action—we should apply our advice.</p><h2 id="binary-aspect-weaving">Binary Aspect Weaving</h2><p>Aspect weaving is the name of the advice applying process. Aspect weaver modifies original code by injecting calls to aspects. AspectJ does exactly that. We give it two binary Java classesFoo.classandMethodLogger.class; it gives back three—modifiedFoo.class,Foo$AjcClosure1.classand unmodifiedMethodLogger.class.</p><aside class="quote">Without weaving, both classes and aspects are just compiled Java binaries with attached annotations</aside><p>In order to understand which advice should be applied to which methods, AspectJ weaver is using annotations from.classfiles. Also, it uses reflection to browse all classes on classpath. It analyzes which methods satisfy the conditions from the@Aroundannotation. Of course, it finds our methodpower().</p><p>So, there are two steps. First, we compile our.javafiles usingjavacand get two files. Then, AspectJ weaves/modifies them and creates its own extra class. OurFooclass looks something like this after weaving:</p><pre> <p>AspectJ weaver moves our original functionality to a new method,public class Foo { private final MethodLogger logger; @Loggable public int power(int x, int p) { return this.logger.around(point); } private int power_aroundBody(int x, int p) { return Math.pow(x, p); } }</pre>power_aroundBody(), and redirects allpower()calls to the aspect classMethodLogger.</p><p>Instead of one methodpower()in classFoonow we have four classes working together. From now on, this is what happens behind the scenes on every call topower():</p><p></p><p>Original functionality of method power()is indicated by the small green lifeline on the diagram.</p><p>As you see, the aspect weaving process connects together classes and aspects, transferring calls between them through join points. Without weaving, both classes and aspects are just compiled Java binaries with attached annotations.</p><h1 id="jcabi-aspects">jcabi-aspects</h1><p>jcabi-aspects is a JAR library that containsLoggableannotation andMethodLoggeraspect (btw, there are many more aspects and annotations). You don’t need to write your own aspect for method logging. Just add a few dependencies to your classpath and configure jcabi-maven-plugin for aspect weaving (get their latest versions in Maven Central):</p><pre> <p>Since this weaving procedure takes a lot of configuration effort, I created a convenient Maven plugin with an<project> <dependencies> <dependency> <groupId>com.jcabi</groupId> <artifactId>jcabi-aspects</artifactId> </dependency> <dependency> <groupId>org.aspectj</groupId> <artifactId>aspectjrt</artifactId> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>com.jcabi</groupId> <artifactId>jcabi-maven-plugin</artifactId> <executions> <execution> <goals> <goal>ajc</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project></pre>ajcgoal, which does the entire aspect weaving job. You can use AspectJ directly, but I recommend that you use jcabi-maven-plugin.</p><p>That’s it. Now you can use@com.jcabi.aspects.Loggableannotation and your methods will be logged through slf4j.</p><p>If something doesn’t work as explained, don’t hesitate to submit a GitHub issue.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Why NULL is Bad? </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/05/13/why-null-is-bad.html>12 Best</li> <li /2014/05/13/why-null-is-bad.html>All 292</li> <li /2014/05/13/why-null-is-bad.html>Webinars</li> <li /2014/05/13/why-null-is-bad.html>Talks</li> <li /2014/05/13/why-null-is-bad.html>Books</li> <li /2014/05/13/why-null-is-bad.html>Papers</li> <li /2014/05/13/why-null-is-bad.html>Pets</li> <li /2014/05/13/why-null-is-bad.html class=”highlighted”>Trainings</li> <li /2014/05/13/why-null-is-bad.html>Award</li> <li /2014/05/13/why-null-is-bad.html>Testimonials</li> <li /2014/05/13/why-null-is-bad.html>Shift-M</li> <li /2014/05/13/why-null-is-bad.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/05/13/why-null-is-bad.html</p><h1 itemprop="name headline mainEntityOfPage">Why NULL is Bad?</h1><aside class='book'>Read more about this subject in Section 2.6
of my book</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="unprintable subline"> <li>Translated:</li> <li>Japanese</li> <li>add yours!</li></ul><p class="unprintable"><p>A simple example of NULLusage in Java:</p><pre> <p>What is wrong with this method?</p><p>It may returnpublic Employee getByName(String name) { int id = database.find(name); if (id == 0) { return null; } return new Employee(id); }</pre>NULLinstead of an object—that’s what is wrong.NULLis a terrible practice in an object-oriented paradigm and should be avoided at all costs. There have been a number of opinions about this published already, including Null References, The Billion Dollar Mistake presentation by Tony Hoare and the entire Object Thinking book by David West.</p><p>Here, I’ll try to summarize all the arguments and show examples of howNULLusage can be avoided and replaced with proper object-oriented constructs.</p><p>Basically, there are two possible alternatives toNULL.</p><p>The first one is Null Object design pattern (the best way is to make it a constant):</p><pre> <p>The second possible alternative is to fail fast by throwing an Exception when you can’t return an object:</p>public Employee getByName(String name) { int id = database.find(name); if (id == 0) { return Employee.NOBODY; } return Employee(id); }</pre><pre> <p>Now, let’s see the arguments againstpublic Employee getByName(String name) { int id = database.find(name); if (id == 0) { throw new EmployeeNotFoundException(name); } return Employee(id); }</pre>NULL.</p><p>Besides Tony Hoare’s presentation and David West’s book mentioned above, I read these publications before writing this post: Clean Code by Robert Martin, Code Complete by Steve McConnell, Say “No” to “Null” by John Sonmez, Is returning null bad design? discussion at StackOverflow.</p><h2 id="ad-hoc-error-handling">Ad-hoc Error Handling</h2><p>Every time you get an object as an input you must check whether it isNULLor a valid object reference. If you forget to check, aNullPointerException(NPE) may break execution in runtime. Thus, your logic becomes polluted with multiple checks and if/then/else forks:</p><pre> <p>This is how exceptional situations are supposed to be handled in C and other imperative procedural languages. OOP introduced exception handling primarily to get rid of these ad-hoc error handling blocks. In OOP, we let exceptions bubble up until they reach an application-wide error handler and our code becomes much cleaner and shorter:</p>// this is a terrible design, don't reuse Employee employee = dept.getByName("Jeffrey"); if (employee == null) { System.out.println("can't find an employee"); System.exit(-1); } else { employee.transferTo(dept2); }</pre><pre> <p>Considerdept.getByName("Jeffrey").transferTo(dept2);</pre>NULLreferences an inheritance of procedural programming, and use 1) Null Objects or 2) Exceptions instead.</p><h2 id="ambiguous-semantic">Ambiguous Semantic</h2><p>In order to explicitly convey its meaning, the functiongetByName()has to be namedgetByNameOrNullIfNotFound(). The same should happen with every function that returns an object orNULL. Otherwise, ambiguity is inevitable for a code reader. Thus, to keep semantic unambiguous, you should give longer names to functions.</p><p>To get rid of this ambiguity, always return a real object, a null object or throw an exception.</p><p>Some may argue that we sometimes have to returnNULL, for the sake of performance. For example, methodget()of interfaceMapin Java returnsNULLwhen there is no such item in the map:</p><pre> <p>This code searches the map only once due to the usage ofEmployee employee = employees.get("Jeffrey"); if (employee == null) { throw new EmployeeNotFoundException(); } return employee;</pre>NULLinMap. If we would refactorMapso that its methodget()will throw an exception if nothing is found, our code will look like this:</p><pre> <p>Obviously, this is method is twice as slow as the first one. What to do?</p><p>Theif (!employees.containsKey("Jeffrey")) { // first search throw new EmployeeNotFoundException(); } return employees.get("Jeffrey"); // second search</pre>Mapinterface (no offense to its authors) has a design flaw. Its methodget()should have been returning anIteratorso that our code would look like:</p><pre> <p>BTW, that is exactly how C++ STL map::find() method is designed.</p><h2 id="computer-thinking-vs-object-thinking">Computer Thinking vs. Object Thinking</h2><p>StatementIterator found = Map.search("Jeffrey"); if (!found.hasNext()) { throw new EmployeeNotFoundException(); } return found.next();</pre>if (employee == null)is understood by someone who knows that an object in Java is a pointer to a data structure and thatNULLis a pointer to nothing (0x00000000, in Intel x86 processors).</p><p>However, if you start thinking as an object, this statement makes much less sense. This is how our code looks from an object point of view:</p><pre> - Hello, is it a software department? - Yes.
- Let me talk to your employee "Jeffrey" please.
- Hold the line please…
- Hello.
- Are you NULL?</code></pre></figure><p>The last question in this conversation sounds weird, doesn’t it?</p><p>Instead, if they hang up the phone after our request to speak to Jeffrey, that causes a problem for us (Exception). At that point, we try to call again or inform our supervisor that we can’t reach Jeffrey and complete a bigger transaction.</p><p>Alternatively, they may let us speak to another person, who is not Jeffrey, but who can help with most of our questions or refuse to help if we need something “Jeffrey specific” (Null Object).</p><h2 id="slow-failing">Slow Failing</h2><p>Instead of failing fast, the code above attempts to die slowly, killing others on its way. Instead of letting everyone know that something went wrong and that an exception handling should start immediately, it is hiding this failure from its client.</p><p>This argument is close to the “ad-hoc error handling” discussed above.</p><p>It is a good practice to make your code as fragile as possible, letting it break when necessary.</p><aside class="youtube"> <div class="box"> <div class="play"></div></div><div>What is Wrong About NULL in OOP? (webinar #3); 3 June 2015.</div></aside><p>Make your methods extremely demanding as to the data they manipulate. Let them complain by throwing exceptions, if the provided data provided is not sufficient or simply doesn’t fit with the main usage scenario of the method.</p><p>Otherwise, return a Null Object, that exposes some common behavior and throws exceptions on all other calls:</p>
<pre> <blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Say, you are designing a method findUserByName(), which has to find a user in the database. What would you return if nothing is found? #elegantobjects</p>— Yegor Bugayenko (@yegor256) April 29, 2018</blockquote> <h2 id="mutable-and-incomplete-objects">Mutable and Incomplete Objects</h2><p>In general, it is highly recommended to design objects with immutability in mind. This means that an object gets all necessary knowledge during its instantiating and never changes its state during the entire life-cycle.</p><p>Very often,public Employee getByName(String name) { int id = database.find(name); Employee employee; if (id == 0) { employee = new Employee() { @Override public String name() { return "anonymous"; } @Override public void transferTo(Department dept) { throw new AnonymousEmployeeException( "I can't be transferred, I'm anonymous" ); } }; } else { employee = Employee(id); } return employee; }</pre>NULLvalues are used in lazy loading, to make objects incomplete and mutable. For example:</p><pre> <p>This technology, although widely used, is an anti-pattern in OOP. Mostly because it makes an object responsible for performance problems of the computational platform, which is something anpublic class Department { private Employee found = null; public synchronized Employee manager() { if (this.found == null) { this.found = new Employee("Jeffrey"); } return this.found; } }</pre>Employeeobject should not be aware of.</p><p>Instead of managing a state and exposing its business-relevant behavior, an object has to take care of the caching of its own results—this is what lazy loading is about.</p><p>Caching is not something an employee does in the office, does he?</p><p>The solution? Don’t use lazy loading in such a primitive way, as in the example above. Instead, move this caching problem to another layer of your application.</p><p>For example, in Java, you can use aspect-oriented programming aspects. For example, jcabi-aspects has@Cacheableannotation that caches the value returned by a method:</p><pre> <p>I hope this analysis was convincing enough that you will stopimport com.jcabi.aspects.Cacheable; public class Department { @Cacheable(forever = true) public Employee manager() { return new Employee("Jacky Brown"); } }</pre>NULL-ing your code :)</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>A simple example ofNULLusage in Java:</p><pre> <p>What is wrong with this method?</p><p>It may returnpublic Employee getByName(String name) { int id = database.find(name); if (id == 0) { return null; } return new Employee(id); }</pre>NULLinstead of an object—that’s what is wrong.NULLis a terrible practice in an object-oriented paradigm and should be avoided at all costs. There have been a number of opinions about this published already, including Null References, The Billion Dollar Mistake presentation by Tony Hoare and the entire Object Thinking book by David West.</p><p>Here, I’ll try to summarize all the arguments and show examples of howNULLusage can be avoided and replaced with proper object-oriented constructs.</p><p>Basically, there are two possible alternatives toNULL.</p><p>The first one is Null Object design pattern (the best way is to make it a constant):</p><pre> <p>The second possible alternative is to fail fast by throwing an Exception when you can’t return an object:</p>public Employee getByName(String name) { int id = database.find(name); if (id == 0) { return Employee.NOBODY; } return Employee(id); }</pre><pre> <p>Now, let’s see the arguments againstpublic Employee getByName(String name) { int id = database.find(name); if (id == 0) { throw new EmployeeNotFoundException(name); } return Employee(id); }</pre>NULL.</p><p>Besides Tony Hoare’s presentation and David West’s book mentioned above, I read these publications before writing this post: Clean Code by Robert Martin, Code Complete by Steve McConnell, Say “No” to “Null” by John Sonmez, Is returning null bad design? discussion at StackOverflow.</p><h2 id="ad-hoc-error-handling">Ad-hoc Error Handling</h2><p>Every time you get an object as an input you must check whether it isNULLor a valid object reference. If you forget to check, aNullPointerException(NPE) may break execution in runtime. Thus, your logic becomes polluted with multiple checks and if/then/else forks:</p><pre> <p>This is how exceptional situations are supposed to be handled in C and other imperative procedural languages. OOP introduced exception handling primarily to get rid of these ad-hoc error handling blocks. In OOP, we let exceptions bubble up until they reach an application-wide error handler and our code becomes much cleaner and shorter:</p>// this is a terrible design, don't reuse Employee employee = dept.getByName("Jeffrey"); if (employee == null) { System.out.println("can't find an employee"); System.exit(-1); } else { employee.transferTo(dept2); }</pre><pre> <p>Considerdept.getByName("Jeffrey").transferTo(dept2);</pre>NULLreferences an inheritance of procedural programming, and use 1) Null Objects or 2) Exceptions instead.</p><h2 id="ambiguous-semantic">Ambiguous Semantic</h2><p>In order to explicitly convey its meaning, the functiongetByName()has to be namedgetByNameOrNullIfNotFound(). The same should happen with every function that returns an object orNULL. Otherwise, ambiguity is inevitable for a code reader. Thus, to keep semantic unambiguous, you should give longer names to functions.</p><p>To get rid of this ambiguity, always return a real object, a null object or throw an exception.</p><p>Some may argue that we sometimes have to returnNULL, for the sake of performance. For example, methodget()of interfaceMapin Java returnsNULLwhen there is no such item in the map:</p><pre> <p>This code searches the map only once due to the usage ofEmployee employee = employees.get("Jeffrey"); if (employee == null) { throw new EmployeeNotFoundException(); } return employee;</pre>NULLinMap. If we would refactorMapso that its methodget()will throw an exception if nothing is found, our code will look like this:</p><pre> <p>Obviously, this is method is twice as slow as the first one. What to do?</p><p>Theif (!employees.containsKey("Jeffrey")) { // first search throw new EmployeeNotFoundException(); } return employees.get("Jeffrey"); // second search</pre>Mapinterface (no offense to its authors) has a design flaw. Its methodget()should have been returning anIteratorso that our code would look like:</p><pre> <p>BTW, that is exactly how C++ STL map::find() method is designed.</p><h2 id="computer-thinking-vs-object-thinking">Computer Thinking vs. Object Thinking</h2><p>StatementIterator found = Map.search("Jeffrey"); if (!found.hasNext()) { throw new EmployeeNotFoundException(); } return found.next();</pre>if (employee == null)is understood by someone who knows that an object in Java is a pointer to a data structure and thatNULLis a pointer to nothing (0x00000000, in Intel x86 processors).</p><p>However, if you start thinking as an object, this statement makes much less sense. This is how our code looks from an object point of view:</p><pre> - Hello, is it a software department? - Yes.
- Let me talk to your employee "Jeffrey" please.
- Hold the line please…
- Hello.
- Are you NULL?</code></pre></figure><p>The last question in this conversation sounds weird, doesn’t it?</p><p>Instead, if they hang up the phone after our request to speak to Jeffrey, that causes a problem for us (Exception). At that point, we try to call again or inform our supervisor that we can’t reach Jeffrey and complete a bigger transaction.</p><p>Alternatively, they may let us speak to another person, who is not Jeffrey, but who can help with most of our questions or refuse to help if we need something “Jeffrey specific” (Null Object).</p><h2 id="slow-failing">Slow Failing</h2><p>Instead of failing fast, the code above attempts to die slowly, killing others on its way. Instead of letting everyone know that something went wrong and that an exception handling should start immediately, it is hiding this failure from its client.</p><p>This argument is close to the “ad-hoc error handling” discussed above.</p><p>It is a good practice to make your code as fragile as possible, letting it break when necessary.</p><aside class="youtube"> <div class="box"> <div class="play"></div></div><div>What is Wrong About NULL in OOP? (webinar #3); 3 June 2015.</div></aside><p>Make your methods extremely demanding as to the data they manipulate. Let them complain by throwing exceptions, if the provided data provided is not sufficient or simply doesn’t fit with the main usage scenario of the method.</p><p>Otherwise, return a Null Object, that exposes some common behavior and throws exceptions on all other calls:</p>
<pre> <blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Say, you are designing a method findUserByName(), which has to find a user in the database. What would you return if nothing is found? #elegantobjects</p>— Yegor Bugayenko (@yegor256) April 29, 2018</blockquote> <h2 id="mutable-and-incomplete-objects">Mutable and Incomplete Objects</h2><p>In general, it is highly recommended to design objects with immutability in mind. This means that an object gets all necessary knowledge during its instantiating and never changes its state during the entire life-cycle.</p><p>Very often,public Employee getByName(String name) { int id = database.find(name); Employee employee; if (id == 0) { employee = new Employee() { @Override public String name() { return "anonymous"; } @Override public void transferTo(Department dept) { throw new AnonymousEmployeeException( "I can't be transferred, I'm anonymous" ); } }; } else { employee = Employee(id); } return employee; }</pre>NULLvalues are used in lazy loading, to make objects incomplete and mutable. For example:</p><pre> <p>This technology, although widely used, is an anti-pattern in OOP. Mostly because it makes an object responsible for performance problems of the computational platform, which is something anpublic class Department { private Employee found = null; public synchronized Employee manager() { if (this.found == null) { this.found = new Employee("Jeffrey"); } return this.found; } }</pre>Employeeobject should not be aware of.</p><p>Instead of managing a state and exposing its business-relevant behavior, an object has to take care of the caching of its own results—this is what lazy loading is about.</p><p>Caching is not something an employee does in the office, does he?</p><p>The solution? Don’t use lazy loading in such a primitive way, as in the example above. Instead, move this caching problem to another layer of your application.</p><p>For example, in Java, you can use aspect-oriented programming aspects. For example, jcabi-aspects has@Cacheableannotation that caches the value returned by a method:</p><pre> <p>I hope this analysis was convincing enough that you will stopimport com.jcabi.aspects.Cacheable; public class Department { @Cacheable(forever = true) public Employee manager() { return new Employee("Jacky Brown"); } }</pre>NULL-ing your code :)</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> OOP Alternative to Utility Classes </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>12 Best</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>All 292</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Webinars</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Talks</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Books</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Papers</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Pets</li> <li /2014/05/05/oop-alternative-to-utility-classes.html class=”highlighted”>Trainings</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Award</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Testimonials</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Shift-M</li> <li /2014/05/05/oop-alternative-to-utility-classes.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html</p><h1 itemprop="name headline mainEntityOfPage">OOP Alternative to Utility Classes</h1><aside class='book'>Read more about this subject in Section 3.2
of my book</aside><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="unprintable subline"> <li>Translated:</li> <li>Japanese</li> <li>Russian</li> <li>add yours!</li></ul><p class="unprintable"><p>A utility class (aka helper class) is a “structure” that has only static methods and encapsulates no state. StringUtils,IOUtils,FileUtilsfrom Apache Commons;IterablesandIteratorsfrom Guava, andFilesfrom JDK7 are perfect examples of utility classes.</p><p>This design idea is very popular in the Java world (as well as C#, Ruby, etc.) because utility classes provide common functionality used everywhere.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>What’s Wrong About Utility Classes? (webinar #6); 2 September 2015.</div></aside><p>Here, we want to follow the DRY principle and avoid duplication. Therefore, we place common code blocks into utility classes and reuse them when necessary:</p><pre> <p>Indeed, this a very convenient technique!?</p><h2 id="utility-classes-are-evil">Utility Classes Are Evil</h2><p>However, in an object-oriented world, utility classes are considered a very bad (some even may say “terrible”) practice.</p><p>There have been many discussions of this subject; to name a few: Are Helper Classes Evil? by Nick Malik, Why helper, singletons and utility classes are mostly bad by Simon Hart, Avoiding Utility Classes by Marshal Ward, Kill That Util Class! by Dhaval Dalal, Helper Classes Are A Code Smell by Rob Bagby.</p><p>Additionally, there are a few questions on StackExchange about utility classes: If a “Utilities” class is evil, where do I put my generic code?, Utility Classes are Evil.</p><p>A dry summary of all their arguments is that utility classes are not proper objects; therefore, they don’t fit into object-oriented world. They were inherited from procedural programming, mostly because we were used to a functional decomposition paradigm back then.</p><p>Assuming you agree with the arguments and want to stop using utility classes, I’ll show by example how these creatures can be replaced with proper objects.</p><h2 id="procedural-example">Procedural Example</h2><p>Say, for instance, you want to read a text file, split it into lines, trim every line and then save the results in another file. This is can be done with// This is a terrible design, don't reuse public class NumberUtils { public static int max(int a, int b) { return a > b ? a : b; } }</pre>FileUtilsfrom Apache Commons:</p><pre> <p>The above code may look clean; however, this is procedural programming, not object-oriented. We are manipulating data (bytes and bits) and explicitly instructing the computer from where to retrieve them and then where to put them on every single line of code. We’re defining a procedure of execution.</p><h2 id="object-oriented-alternative">Object-Oriented Alternative</h2><p>In an object-oriented paradigm, we should instantiate and compose objects, thus letting them manage data when and how they desire. Instead of calling supplementary static functions, we should create objects that are capable of exposing the behavior we are seeking:</p>void transform(File in, File out) { Collection<String> src = FileUtils.readLines(in, "UTF-8"); Collection<String> dest = new ArrayList<>(src.size()); for (String line : src) { dest.add(line.trim()); } FileUtils.writeLines(out, dest, "UTF-8"); }</pre><pre> <p>This procedural call:</p>public class Max implements Number { private final int a; private final int b; public Max(int x, int y) { this.a = x; this.b = y; } @Override public int intValue() { return this.a > this.b ? this.a : this.b; } }</pre><pre> <p>Will become object-oriented:</p>int max = NumberUtils.max(10, 5);</pre><pre> <p>Potato, potato? Not really; just read on…</p><h2 id="objects-instead-of-data-structures">Objects Instead of Data Structures</h2><p>This is how I would design the same file-transforming functionality as above but in an object-oriented manner:</p>int max = new Max(10, 5).intValue();</pre><pre> <p>void transform(File in, File out) { Collection<String> src = new Trimmed( new FileLines(new UnicodeFile(in)) ); Collection<String> dest = new FileLines( new UnicodeFile(out) ); dest.addAll(src); }</pre>FileLinesimplementsCollection<String>and encapsulates all file reading and writing operations. An instance ofFileLinesbehaves exactly as a collection of strings and hides all I/O operations. When we iterate it—a file is being read. When weaddAll()to it—a file is being written.</p><p>Trimmedalso implementsCollection<String>and encapsulates a collection of strings (Decorator pattern). Every time the next line is retrieved, it gets trimmed.</p><p>All classes taking participation in the snippet are rather small:Trimmed,FileLines, andUnicodeFile. Each of them is responsible for its own single feature, thus following perfectly the single responsibility principle.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Objects vs. Static Methods (webinar #1); 8 April 2015.</div></aside><p>On our side, as users of the library, this may be not so important, but for their developers it is an imperative. It is much easier to develop, maintain and unit-test class FileLinesrather than using areadLines()method in a 80+ methods and 3000 lines utility classFileUtils. Seriously, look at its source code.</p><p>An object-oriented approach enables lazy execution. Theinfile is not read until its data is required. If we fail to openoutdue to some I/O error, the first file won’t even be touched. The whole show starts only after we calladdAll().</p><p>All lines in the second snippet, except the last one, instantiate and compose smaller objects into bigger ones. This object composition is rather cheap for the CPU since it doesn’t cause any data transformations.</p><p>Besides that, it is obvious that the second script runs in O(1) space, while the first one executes in O(n). This is the consequence of our procedural approach to data in the first script.</p><p>In an object-oriented world, there is no data; there are only objects and their behavior!</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>A utility class (aka helper class) is a “structure” that has only static methods and encapsulates no state.StringUtils,IOUtils,FileUtilsfrom Apache Commons;IterablesandIteratorsfrom Guava, andFilesfrom JDK7 are perfect examples of utility classes.</p><p>This design idea is very popular in the Java world (as well as C#, Ruby, etc.) because utility classes provide common functionality used everywhere.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>What’s Wrong About Utility Classes? (webinar #6); 2 September 2015.</div></aside><p>Here, we want to follow the DRY principle and avoid duplication. Therefore, we place common code blocks into utility classes and reuse them when necessary:</p><pre> <p>Indeed, this a very convenient technique!?</p><h2 id="utility-classes-are-evil">Utility Classes Are Evil</h2><p>However, in an object-oriented world, utility classes are considered a very bad (some even may say “terrible”) practice.</p><p>There have been many discussions of this subject; to name a few: Are Helper Classes Evil? by Nick Malik, Why helper, singletons and utility classes are mostly bad by Simon Hart, Avoiding Utility Classes by Marshal Ward, Kill That Util Class! by Dhaval Dalal, Helper Classes Are A Code Smell by Rob Bagby.</p><p>Additionally, there are a few questions on StackExchange about utility classes: If a “Utilities” class is evil, where do I put my generic code?, Utility Classes are Evil.</p><p>A dry summary of all their arguments is that utility classes are not proper objects; therefore, they don’t fit into object-oriented world. They were inherited from procedural programming, mostly because we were used to a functional decomposition paradigm back then.</p><p>Assuming you agree with the arguments and want to stop using utility classes, I’ll show by example how these creatures can be replaced with proper objects.</p><h2 id="procedural-example">Procedural Example</h2><p>Say, for instance, you want to read a text file, split it into lines, trim every line and then save the results in another file. This is can be done with// This is a terrible design, don't reuse public class NumberUtils { public static int max(int a, int b) { return a > b ? a : b; } }</pre>FileUtilsfrom Apache Commons:</p><pre> <p>The above code may look clean; however, this is procedural programming, not object-oriented. We are manipulating data (bytes and bits) and explicitly instructing the computer from where to retrieve them and then where to put them on every single line of code. We’re defining a procedure of execution.</p><h2 id="object-oriented-alternative">Object-Oriented Alternative</h2><p>In an object-oriented paradigm, we should instantiate and compose objects, thus letting them manage data when and how they desire. Instead of calling supplementary static functions, we should create objects that are capable of exposing the behavior we are seeking:</p>void transform(File in, File out) { Collection<String> src = FileUtils.readLines(in, "UTF-8"); Collection<String> dest = new ArrayList<>(src.size()); for (String line : src) { dest.add(line.trim()); } FileUtils.writeLines(out, dest, "UTF-8"); }</pre><pre> <p>This procedural call:</p>public class Max implements Number { private final int a; private final int b; public Max(int x, int y) { this.a = x; this.b = y; } @Override public int intValue() { return this.a > this.b ? this.a : this.b; } }</pre><pre> <p>Will become object-oriented:</p>int max = NumberUtils.max(10, 5);</pre><pre> <p>Potato, potato? Not really; just read on…</p><h2 id="objects-instead-of-data-structures">Objects Instead of Data Structures</h2><p>This is how I would design the same file-transforming functionality as above but in an object-oriented manner:</p>int max = new Max(10, 5).intValue();</pre><pre> <p>void transform(File in, File out) { Collection<String> src = new Trimmed( new FileLines(new UnicodeFile(in)) ); Collection<String> dest = new FileLines( new UnicodeFile(out) ); dest.addAll(src); }</pre>FileLinesimplementsCollection<String>and encapsulates all file reading and writing operations. An instance ofFileLinesbehaves exactly as a collection of strings and hides all I/O operations. When we iterate it—a file is being read. When weaddAll()to it—a file is being written.</p><p>Trimmedalso implementsCollection<String>and encapsulates a collection of strings (Decorator pattern). Every time the next line is retrieved, it gets trimmed.</p><p>All classes taking participation in the snippet are rather small:Trimmed,FileLines, andUnicodeFile. Each of them is responsible for its own single feature, thus following perfectly the single responsibility principle.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>Objects vs. Static Methods (webinar #1); 8 April 2015.</div></aside><p>On our side, as users of the library, this may be not so important, but for their developers it is an imperative. It is much easier to develop, maintain and unit-test class FileLinesrather than using areadLines()method in a 80+ methods and 3000 lines utility classFileUtils. Seriously, look at its source code.</p><p>An object-oriented approach enables lazy execution. Theinfile is not read until its data is required. If we fail to openoutdue to some I/O error, the first file won’t even be touched. The whole show starts only after we calladdAll().</p><p>All lines in the second snippet, except the last one, instantiate and compose smaller objects into bigger ones. This object composition is rather cheap for the CPU since it doesn’t cause any data transformations.</p><p>Besides that, it is obvious that the second script runs in O(1) space, while the first one executes in O(n). This is the consequence of our procedural approach to data in the first script.</p><p>In an object-oriented world, there is no data; there are only objects and their behavior!</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> Typical Mistakes in Java Code </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/04/27/typical-mistakes-in-java-code.html>12 Best</li> <li /2014/04/27/typical-mistakes-in-java-code.html>All 292</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Webinars</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Talks</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Books</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Papers</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Pets</li> <li /2014/04/27/typical-mistakes-in-java-code.html class=”highlighted”>Trainings</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Award</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Testimonials</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Shift-M</li> <li /2014/04/27/typical-mistakes-in-java-code.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/04/27/typical-mistakes-in-java-code.html</p><h1 itemprop="name headline mainEntityOfPage">Typical Mistakes in Java Code</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><ul class="unprintable subline"> <li>Translated:</li> <li>Chinese</li> <li>add yours!</li></ul><p class="unprintable"><p>This page contains most typical mistakes I see in the Java code of people working with me. Static analysis (we’re using qulice can’t catch all of the mistakes for obvious reasons, and that’s why I decided to list them all here.</p><p>Let me know if you want to see something else added here, and I’ll be happy to oblige.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>A Few Thoughts About Constructors in OOP (webinar #7); 7 October 2015.</div></aside><p>All of the listed mistakes are related to object-oriented programming in general and to Java in particular.</p><h2 id="class-names">Class Names</h2><p>Your class should be an abstraction of a real life entity with no “validators,” “controllers,” “managers,” etc. If your class name ends with an “-er”—it’s a bad design. BTW, here are my seven virtues of a good object. Also, this post explains this idea in more details: Don’t Create Objects That End With -ER.</p><p>And, of course, utility classes are anti-patterns, like StringUtils,FileUtils, andIOUtilsfrom Apache. The above are perfect examples of terrible designs. Read this follow up post: OOP Alternative to Utility Classes</p><p>Of course, never add suffixes or prefixes to distinguish between interfaces and classes. For example, all of these names are terribly wrong:IRecord,IfaceEmployee, orRecordInterface. Usually, interface name is the name of a real-life entity, while class name should explain its implementation details. If there is nothing specific to say about an implementation, name itDefault,Simple, or something similar. For example:</p><pre>class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};</pre><h2 id="method-names">Method Names</h2><p>Methods can either return something or returnvoid. If a method returns something, then its name should explain what it returns, for example (don’t use thegetprefix ever):</p><pre>boolean isValid(String name); String content(); int ageOf(File file);</pre><p>If it returnsvoid,then its name should explain what it does. For example:</p><pre>void save(File file); void process(Work work); void append(File file, String line);</pre><p>You can read more about this idea in Elegant Objects book, section 2.4. There is only one exception to the rule just mentioned—test methods for JUnit. They are explained below.</p><h2 id="test-method-names">Test Method Names</h2><p>Method names in JUnit tests should be created as English sentences without spaces. It’s easier to explain by example:</p><pre>/** - HttpRequest can return its content in Unicode.
- @throws Exception If test fails */ @Test public void returnsItsContentInUnicode() throws Exception { } </code></pre><p>It’s important to start the first sentence of your Javadoc with the name of the class you’re testing followed by
can(orcannot). So, your first sentence should always be similar to “somebody can do something.”</p><p>The method name will state exactly the same, but without the subject. If I add a subject at the beginning of the method name, I should get a complete English sentence, as in above example: “HttpRequestreturns its content in Unicode.”</p><p>Pay attention that the test method doesn’t start withcan. Only Javadoc comments use ‘can.’</p><p>It’s a good practice to always declare test methods as throwingException.</p><h2 id="variable-names">Variable Names</h2><p>Avoid composite names of variables, liketimeOfDay,firstItem, orhttpRequest. I mean with both—class variables and in-method ones. A variable name should be long enough to avoid ambiguity in its scope of visibility, but not too long if possible. A name should be a noun in singular or plural form, or an appropriate abbreviation. More about it in this post: A Compound Name Is a Code Smell. For example:</p><pre>List<String> names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request;</pre><p>Sometimes, you may have collisions between constructor parameters and in-class properties if the constructor saves incoming data in an instantiated object. In this case, I recommend to create abbreviations by removing vowels (see how USPS abbreviates street names).</p><p>Another example:</p><pre>public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } }</pre><p>In many cases, the best hint for a name of a variable can ascertained by reading its class name. Just write it with a small letter, and you should be good:</p><pre>File file; User user; Branch branch;</pre><p>However, never do the same for primitive types, likeInteger numberorString string.</p><p>You can also use an adjective, when there are multiple variables with different characteristics. For instance:</p><pre>String contact(String left, String right);</pre><h2 id="constructors">Constructors</h2><p>Without exceptions, there should be only one constructor that stores data in object variables. All other constructors should call this one with different arguments. For example:</p><pre>public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }</pre><p>More about it in There Can Be Only One Primary Constructor.</p><h2 id="one-time-variables">One-time Variables</h2><p>Avoid one-time variables at all costs. By “one-time” I mean variables that are used only once. Like in this example:</p><pre>String name = "data.txt"; return new File(name);</pre><p>This above variable is used only once and the code should be refactored to:</p><pre>return new File("data.txt");</pre><p>Sometimes, in very rare cases—mostly because of better formatting—one-time variables may be used. Nevertheless, try to avoid such situations at all costs.</p><h2 id="exceptions">Exceptions</h2><p>Needless to say, you should never swallow exceptions, but rather let them bubble up as high as possible. Private methods should always let checked exceptions go out.</p><p>Never use exceptions for flow control. For example this code is wrong:</p><pre>int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; }</pre><p>Seriously, what if thatIOExceptionsays “disk is full?” Will you still assume that the size of the file is zero and move on?</p><h2 id="indentation">Indentation</h2><p>For indentation, the main rule is that a bracket should either end a line or be closed on the same line (reverse rule applies to a closing bracket). For example, the following is not correct because the first bracket is not closed on the same line and there are symbols after it. The second bracket is also in trouble because there are symbols in front of it and it is not opened on the same line:</p><pre>final File file = new File(directory, "file.txt");</pre><p>Correct indentation should look like:</p><pre>StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" );</pre><p>The second important rule of indentation says that you should put as much as possible on one line - within the limit of 80 characters. The example above is not valid since it can be compacted:</p><pre>StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );</pre><h2 id="redundant-constants">Redundant Constants</h2><p>Class constants should be used when you want to share information between class methods, and this information is a characteristic (!) of your class. Don’t use constants as a replacement of string or numeric literals—very bad practice that leads to code pollution. Constants (as with any object in OOP) should have a meaning in a real world. What meaning do these constants have in the real world:</p><pre>class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice }</pre><p>Another typical mistake is to use constants in unit tests to avoid duplicate string/numeric literals in test methods. Don’t do this! Every test method should work with its own set of input values.</p><p>Use new texts and numbers in every new test method. They are independent. So, why do they have to share the same input constants?</p><h2 id="test-data-coupling">Test Data Coupling</h2><p>This is an example of data coupling in a test method:</p><pre>User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff"));</pre><p>On the last line, we couple"Jeff"with the same string literal from the first line. If, a few months later, someone wants to change the value on the third line, he/she has to spend extra time finding where else"Jeff"is used in the same method.</p><p>To avoid this data coupling, you should introduce a variable. More about it here: A Few Thoughts on Unit Test Scaffolding.</p></p><nav class="buttons notranslate desktop-only"> 0 0 0 0 0 0 </nav> </header> <article class="main" itemprop="articleBody"><div ><p>This page contains most typical mistakes I see in the Java code of people working with me. Static analysis (we’re using qulice can’t catch all of the mistakes for obvious reasons, and that’s why I decided to list them all here.</p><p>Let me know if you want to see something else added here, and I’ll be happy to oblige.</p><aside class="youtube"> <div class="box"><div class="play"></div></div><div>A Few Thoughts About Constructors in OOP (webinar #7); 7 October 2015.</div></aside><p>All of the listed mistakes are related to object-oriented programming in general and to Java in particular.</p><h2 id="class-names">Class Names</h2><p>Your class should be an abstraction of a real life entity with no “validators,” “controllers,” “managers,” etc. If your class name ends with an “-er”—it’s a bad design. BTW, here are my seven virtues of a good object. Also, this post explains this idea in more details: Don’t Create Objects That End With -ER.</p><p>And, of course, utility classes are anti-patterns, like StringUtils,FileUtils, andIOUtilsfrom Apache. The above are perfect examples of terrible designs. Read this follow up post: OOP Alternative to Utility Classes</p><p>Of course, never add suffixes or prefixes to distinguish between interfaces and classes. For example, all of these names are terribly wrong:IRecord,IfaceEmployee, orRecordInterface. Usually, interface name is the name of a real-life entity, while class name should explain its implementation details. If there is nothing specific to say about an implementation, name itDefault,Simple, or something similar. For example:</p><pre>class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};</pre><h2 id="method-names">Method Names</h2><p>Methods can either return something or returnvoid. If a method returns something, then its name should explain what it returns, for example (don’t use thegetprefix ever):</p><pre>boolean isValid(String name); String content(); int ageOf(File file);</pre><p>If it returnsvoid,then its name should explain what it does. For example:</p><pre>void save(File file); void process(Work work); void append(File file, String line);</pre><p>You can read more about this idea in Elegant Objects book, section 2.4. There is only one exception to the rule just mentioned—test methods for JUnit. They are explained below.</p><h2 id="test-method-names">Test Method Names</h2><p>Method names in JUnit tests should be created as English sentences without spaces. It’s easier to explain by example:</p><pre>/** - HttpRequest can return its content in Unicode.
- @throws Exception If test fails */ @Test public void returnsItsContentInUnicode() throws Exception { } </code></pre><p>It’s important to start the first sentence of your Javadoc with the name of the class you’re testing followed by
can(orcannot). So, your first sentence should always be similar to “somebody can do something.”</p><p>The method name will state exactly the same, but without the subject. If I add a subject at the beginning of the method name, I should get a complete English sentence, as in above example: “HttpRequestreturns its content in Unicode.”</p><p>Pay attention that the test method doesn’t start withcan. Only Javadoc comments use ‘can.’</p><p>It’s a good practice to always declare test methods as throwingException.</p><h2 id="variable-names">Variable Names</h2><p>Avoid composite names of variables, liketimeOfDay,firstItem, orhttpRequest. I mean with both—class variables and in-method ones. A variable name should be long enough to avoid ambiguity in its scope of visibility, but not too long if possible. A name should be a noun in singular or plural form, or an appropriate abbreviation. More about it in this post: A Compound Name Is a Code Smell. For example:</p><pre>List<String> names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request;</pre><p>Sometimes, you may have collisions between constructor parameters and in-class properties if the constructor saves incoming data in an instantiated object. In this case, I recommend to create abbreviations by removing vowels (see how USPS abbreviates street names).</p><p>Another example:</p><pre>public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } }</pre><p>In many cases, the best hint for a name of a variable can ascertained by reading its class name. Just write it with a small letter, and you should be good:</p><pre>File file; User user; Branch branch;</pre><p>However, never do the same for primitive types, likeInteger numberorString string.</p><p>You can also use an adjective, when there are multiple variables with different characteristics. For instance:</p><pre>String contact(String left, String right);</pre><h2 id="constructors">Constructors</h2><p>Without exceptions, there should be only one constructor that stores data in object variables. All other constructors should call this one with different arguments. For example:</p><pre>public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }</pre><p>More about it in There Can Be Only One Primary Constructor.</p><h2 id="one-time-variables">One-time Variables</h2><p>Avoid one-time variables at all costs. By “one-time” I mean variables that are used only once. Like in this example:</p><pre>String name = "data.txt"; return new File(name);</pre><p>This above variable is used only once and the code should be refactored to:</p><pre>return new File("data.txt");</pre><p>Sometimes, in very rare cases—mostly because of better formatting—one-time variables may be used. Nevertheless, try to avoid such situations at all costs.</p><h2 id="exceptions">Exceptions</h2><p>Needless to say, you should never swallow exceptions, but rather let them bubble up as high as possible. Private methods should always let checked exceptions go out.</p><p>Never use exceptions for flow control. For example this code is wrong:</p><pre>int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; }</pre><p>Seriously, what if thatIOExceptionsays “disk is full?” Will you still assume that the size of the file is zero and move on?</p><h2 id="indentation">Indentation</h2><p>For indentation, the main rule is that a bracket should either end a line or be closed on the same line (reverse rule applies to a closing bracket). For example, the following is not correct because the first bracket is not closed on the same line and there are symbols after it. The second bracket is also in trouble because there are symbols in front of it and it is not opened on the same line:</p><pre>final File file = new File(directory, "file.txt");</pre><p>Correct indentation should look like:</p><pre>StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" );</pre><p>The second important rule of indentation says that you should put as much as possible on one line - within the limit of 80 characters. The example above is not valid since it can be compacted:</p><pre>StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );</pre><h2 id="redundant-constants">Redundant Constants</h2><p>Class constants should be used when you want to share information between class methods, and this information is a characteristic (!) of your class. Don’t use constants as a replacement of string or numeric literals—very bad practice that leads to code pollution. Constants (as with any object in OOP) should have a meaning in a real world. What meaning do these constants have in the real world:</p><pre>class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice }</pre><p>Another typical mistake is to use constants in unit tests to avoid duplicate string/numeric literals in test methods. Don’t do this! Every test method should work with its own set of input values.</p><p>Use new texts and numbers in every new test method. They are independent. So, why do they have to share the same input constants?</p><h2 id="test-data-coupling">Test Data Coupling</h2><p>This is an example of data coupling in a test method:</p><pre>User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff"));</pre><p>On the last line, we couple"Jeff"with the same string literal from the first line. If, a few months later, someone wants to change the value on the third line, he/she has to spend extra time finding where else"Jeff"is used in the same method.</p><p>To avoid this data coupling, you should introduce a variable. More about it here: A Few Thoughts on Unit Test Scaffolding.</p></div></article></div><div class="wrapper"></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;"> How Much Do You Pay Per Line of Code? </head> <body><div class="wrapper"> <aside class="header-toggle unprintable" id="header-toggle" title="Show the menu" onclick="$('#header').show();$('#header-toggle').hide();">☰</aside> <header class="header" id="header"><div class="face"> Subscribe </div><nav><ul class="menu social notranslate"> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li> <li></li></ul><ul class="menu"> <li>Home</li> <li /2014/04/11/cost-of-loc.html>12 Best</li> <li /2014/04/11/cost-of-loc.html>All 292</li> <li /2014/04/11/cost-of-loc.html>Webinars</li> <li /2014/04/11/cost-of-loc.html>Talks</li> <li /2014/04/11/cost-of-loc.html>Books</li> <li /2014/04/11/cost-of-loc.html>Papers</li> <li /2014/04/11/cost-of-loc.html>Pets</li> <li /2014/04/11/cost-of-loc.html class=”highlighted”>Trainings</li> <li /2014/04/11/cost-of-loc.html>Award</li> <li /2014/04/11/cost-of-loc.html>Testimonials</li> <li /2014/04/11/cost-of-loc.html>Shift-M</li> <li /2014/04/11/cost-of-loc.html>Paintings</li> <li>По-русски</li></ul></nav><div class="search"> <form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction"> </form></div><div class="hot"><ul></ul></div></header></div><section itemscope="" itemtype="http://schema.org/BlogPosting"><div class="wrapper"> <header><p class="printable"> </p><p class="printable">
https://www.yegor256.com/2014/04/11/cost-of-loc.html</p><h1 itemprop="name headline mainEntityOfPage">How Much Do You Pay Per Line of Code?</h1><ul class="subline"> <li> </li> <li class="printable" itemscope="" itemprop="author" itemtype="http://schema.org/Person"> Yegor Bugayenko </li> <li class="unprintable"> comments </li></ul><p class="unprintable">cloc.pl.</p><p>It was a commercial project, so I can’t disclose its name.</p>
<figcaption id="51e79012">Brazil (1985) by Terry Gilliam</figcaption>
<figcaption>Shaolin Temple (1982) by Chang Hsin Yen</figcaption>masterbranch, which totals 88k lines of code. The project resulted in about 10,000 man hours to produce these lines (20 programmers, three months, 170 working hours per month)—which equates to about $350k. Therefore, the project cost a whopping</p><p class="red center em2">$3.98 per line</p><p>The second project, in the same three month period, produced 45k new lines and removed 9k, which comes to 54k in all. To complete this work, we spent only $7k (approximately 350 working hours in 650 tasks). Thus, the project cost merely:</p><p class="green center em2">¢13 per line</p><p>This also means that programmers were writing approximately 150 lines per hour or over a thousand per day. The Mythical Man-Month talks about 10 lines per day, which is a hundred times less than we saw in our project.</p><p>$350k vs $7k, $3.98 vs ¢13? What do you think?</p><h2 id="how-to-validate-the-numbers">How to Validate the Numbers?</h2><p>If you’re curious, I’m using hoc to get the numbers from Git (it is explained in Hits-of-Code Instead of SLoC). You can validate the numbers for the second project here on GitHub: jcabi/jcabi-github.</p><h2 id="conclusion">Conclusion</h2><p>What I’m trying to express with these numbers is that distributed programming is much more effective, money-wise, than a co-located team. Again, I can hear you saying that “line of code” is not a proper metric. But, come on, $0.13 vs. $3.98? Thirty times more expensive?</p>
<figcaption>The Big Lebowski (1998) by Joel Coen</figcaption>cloc.pl.</p><p>It was a commercial project, so I can’t disclose its name.</p>masterbranch, which totals 88k lines of code. The project resulted in about 10,000 man hours to produce these lines (20 programmers, three months, 170 working hours per month)—which equates to about $350k. Therefore, the project cost a whopping</p><p class="red center em2">$3.98 per line</p><p>The second project, in the same three month period, produced 45k new lines and removed 9k, which comes to 54k in all. To complete this work, we spent only $7k (approximately 350 working hours in 650 tasks). Thus, the project cost merely:</p><p class="green center em2">¢13 per line</p><p>This also means that programmers were writing approximately 150 lines per hour or over a thousand per day. The Mythical Man-Month talks about 10 lines per day, which is a hundred times less than we saw in our project.</p><p>$350k vs $7k, $3.98 vs ¢13? What do you think?</p><h2 id="how-to-validate-the-numbers">How to Validate the Numbers?</h2><p>If you’re curious, I’m using hoc to get the numbers from Git (it is explained in Hits-of-Code Instead of SLoC). You can validate the numbers for the second project here on GitHub: jcabi/jcabi-github.</p><h2 id="conclusion">Conclusion</h2><p>What I’m trying to express with these numbers is that distributed programming is much more effective, money-wise, than a co-located team. Again, I can hear you saying that “line of code” is not a proper metric. But, come on, $0.13 vs. $3.98? Thirty times more expensive?</p></div><div class="disqus" role="complementary"><p class="disqus_hint"> Please, use syntax highlighting in your comments, to make them more readable.</p><div id="disqus_thread" class="disqus-thread"> </div> </div><div class="wrapper"> <footer class="footer"><p> © Yegor Bugayenko 2014–2018</p></footer></div></section><div class="wrapper unprintable" style="text-align:center;margin-top:2em;">
